search

emailhippo / email-verify-api-v3-client-wrapper

Apache License 2.0
5 stars 1 forks source link

disable stylecop! #1

Closed s123klippel closed 7 years ago

s123klippel commented 7 years ago

How on earth do I disable stylecop? This thing is horrible.

emh-rowland-oconnor commented 7 years ago

Hi

Please elaborate on 'horrible'?

s123klippel commented 7 years ago

I can. We already have our own code styles defined by way of Microsoft code analysis and resharper. The default styles for stylecop are conflicting and unnecessary.

Furthermore, it is architecturally unacceptable for a third party library to link any form of code analysis. That is a top down implementation, not bottom up. What if every library linked a different analysis library? Can you imagine the chaos and conflict?

My company is poised to spend thousands of dollars a month with emailhippo. This makes me question that choice.

On May 25, 2017 8:16 PM, emh-rowland-oconnor notifications@github.com wrote:

Hi

Please elaborate on 'horrible'?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHubhttps://github.com/emailhippo/email-verify-api-v3-client-wrapper/issues/1#issuecomment-304157828, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AQ1LScuPAtVgKs64jLEwOu9lD3Qab5zQks5r9hnEgaJpZM4Nmilu.

emh-rowland-oconnor commented 7 years ago

Hi.

Thanks for the clarification and considering Email Hippo services.

Points noted with thanks.

As someone with a historic and future interest in .NET (Email Hippo is built .NET and hosted in Azure BTW), I'm taking some time to respond in detail because I think that the points raised are interesting and warrant further discussion and explanation

Free Market & Choices

On the consideration of our services based on this, Email Hippo respects and encourages freedom of choice when it comes to selecting a provider so we are of course cool with your comments on reviewing decisions etc. Our services compete in an open market and we recognise that, like any other business, that our services are not necessarily for everyone. Where we do focus our attention is on innovation of features, uptime, performance and data security as these things are what many customers have told us that are predominantly important to them.

Our integration software (of which we only ship and support .NET natively although others are available via swagger.io code gen). Additionally, we open-sourced our libraries with the specific intent of encouraging adaptation (fork as needed).

Architectural Issues

On the question of code QA, I would take an alternative perspective on the architectural acceptability of shipping tooling (e.g. code quality analysers) and offer further background substantiation for your consideration and review.

Roslyn

Since VS2015, Microsft has unbundled it's tooling extension points and made these available to run under it's Roslyn. Microsoft and other third party vendors (ourselves included) therefore take a differing view point of view as far as the architectural suitability of including tooling in package builds. As an example, for another piece of great QA tooling that we use us Jetbrains Annotations (The same vendor that makes R# - incidentally we use R# too - great tool!)

Risks and Benefits of Tooling Options

The benefits of placing tooling in the packages themselves for us are:

Future?

The .NET ecosystem is changing at an incredibly fast pace with BCL unbundling and open sourcing. It's a fascinating time to be a .NET engineer!

As far as tooling (the location thereof as in IDE or package) is concerned, with the advent of Roslyn, where this is ultimately heading is up for grabs. JetBrains do seem to be embracing the concept of package based tooling though - read into this what you will.

Wrap Up

Once again, thanks for taking time to clarify your views. I truly appreciate and enjoy hearing from our customers (also, it give me an excuse to dodge the non-technical bits of steering emailhippo.com and dive right back into the tech (which is my true passion))

Hopefully, this makes sense (although you might not agree with the decision) and explains why we chose 'horrible' package based stylecop.

If our team can help in anyway with your implementation, please let me know (here or through our support system. If you choose an alternative path/provider, I wish you the best too.

Kind regards,

Rowland O'Connor, CEO (and .NET nerd (still after 18 years of .NET!)) emailhippo.com

p.s. I'll leave this issue open for a few days to give time for comments / questions etc. For a faster response, I recommend support system but I'm completely relaxed following this up publicly here too as per your wishes.

s123klippel commented 7 years ago

Hello Again.

I’m not trying to say that StyleCop is horrible, or that you should not use it. It’s the pushing it to a library package repo that is the trouble.

More to the point, when you build for the NuGet target, the StyleCop dependency should be excluded. You are imposing StyleCop on everyone that installs the package, even though they are not downloading the code, forcing them to create custom analysis rules to exclude or make compatible to each unique situation. References can be conditional to specific configurations, though you may need to use compile conditions in code if any of your StyleCop configuration is code based.

For those that fork/download the source, they should of course expect to accept whatever tooling is included and adjust for it. They can quickly drop the reference if they so desire, rather than spend time creating custom rulesets.

From: emh-rowland-oconnor [mailto:notifications@github.com] Sent: Friday, May 26, 2017 10:14 AM To: emailhippo/email-verify-api-v3-client-wrapper email-verify-api-v3-client-wrapper@noreply.github.com Cc: Brian Klippel brian.klippel@synthio.com; Author author@noreply.github.com Subject: Re: [emailhippo/email-verify-api-v3-client-wrapper] disable stylecop! (#1)

Hi.

Thanks for the clarification and considering Email Hippo services.

Points noted with thanks.

As someone with a historic and future interest in .NET (Email Hippo is built .NET and hosted in Azure BTW), I'm taking some time to respond in detail because I think that the points raised are interesting and warrant further discussion and explanation

Free Market & Choices

On the consideration of our services based on this, Email Hippo respects and encourages freedom of choice when it comes to selecting a provider so we are of course cool with your comments on reviewing decisions etc. Our services compete in an open market and we recognise that, like any other business, that our services are not necessarily for everyone. Where we do focus our attention is on innovation of features, uptime, performance and data security as these things are what many customers have told us that are predominantly important to them.

Our integration software (of which we only ship and support .NET natively although others are available via swagger.io code genhttps://api-docs.emailhippo.com/en/latest/client-libraries.html). Additionally, we open-sourced our libraries with the specific intent of encouraging adaptation (fork as needed).

Architectural Issues

On the question of code QA, I would take an alternative perspective on the architectural acceptability of shipping tooling (e.g. code quality analysers) and offer further background substantiation for your consideration and review.

Roslyn

Since VS2015, Microsft has unbundled it's tooling extension points and made these available to run under it's Roslynhttps://github.com/dotnet/roslyn. Microsoft and other third party vendors (ourselves included) therefore take a differing view point of view as far as the architectural suitability of including tooling in package builds. As an example, for another piece of great QA tooling that we use us Jetbrains Annotationshttps://www.nuget.org/packages/JetBrains.Annotations/ (The same vendor that makes R# - incidentally we use R# too - great tool!)

Risks and Benefits of Tooling Options

The benefits of placing tooling in the packages themselves for us are:

· Builds: Code analysis audit runs as part of CI in build environment (no need for VS to be installed on build server)

· Isolation from effects of abandonware: We've historically (since 2009 - VS2008 at that time) had many issues with R# and native VS based tooling. Specifically, the "abandonware"https://stylecop.codeplex.com/discussions/644152 nature of StyleCop itself has caused us pain in terms of not being free to move VS versions due to lack of support. Obviously, at this time, StypeCop is very much alive mostly in part to JetBrains picking it up (a good thing for sure) but if anything has been learned it is that we cannot afford to be too reliant on VS extensions for our core software production quality gates.

· StyleCop conficts: StyleCop conflicts and R# are something that have been around for as long as I can remember (certainly back to VS2008). R# code cleanup has always (and still does perhaps?) had conflicts with StyleCop. By using a Roslyn tool, we achieve better consistency of rules. The improvement in consistency of rules applies not only on local, individual developer machines but across the full estate including all developer machines, CI environments etc. I suspect that it is this consistency of rules that is the source for your complaint.

Future?

The .NET ecosystem is changing at an incredibly fast pace with BCL unbundling and open sourcing. It's a fascinating time to be a .NET engineer!

As far as tooling (the location thereof as in IDE or package) is concerned, with the advent of Roslyn, where this is ultimately heading is up for grabs. JetBrains do seem to be embracing the concept of package based tooling though - read into this what you will.

Wrap Up

Once again, thanks for taking time to clarify your views. I truly appreciate and enjoy hearing from our customers (also, it give me an excuse to dodge the non-technical bits of steering emailhippo.com and dive right back into the tech (which is my true passion))

Hopefully, this makes sense (although you might not agree with the decision) and explains why we chose 'horrible' package based stylecop.

If our team can help in anyway with your implementation, please let me know (here or through our support systemhttps://help.emailhippo.com. If you choose an alternative path/provider, I wish you the best too.

Kind regards,

Rowland O'Connor, CEO (and .NET nerd (still after 18 years of .NET!)) emailhippo.comhttps://www.emailhippo.com

p.s. I'll leave this issue open for a few days to give time for comments / questions etc. For a faster response, I recommend support systemhttps://help.emailhippo.com but I'm completely relaxed following this up publicly here too as per your wishes.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHubhttps://github.com/emailhippo/email-verify-api-v3-client-wrapper/issues/1#issuecomment-304292732, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AQ1LSbO3yvRV3nPPXI94D0tIMw8_WmdGks5r9t4OgaJpZM4Nmilu.

emh-rowland-oconnor commented 7 years ago

We could do something like this.

Any good?

s123klippel commented 7 years ago

That’s probably all that is necessary if the dll reference isn’t used at runtime.

There’s also something like this in the project file, but it might be overkill:

From: emh-rowland-oconnor [mailto:notifications@github.com] Sent: Friday, May 26, 2017 11:24 AM To: emailhippo/email-verify-api-v3-client-wrapper email-verify-api-v3-client-wrapper@noreply.github.com Cc: Brian Klippel brian.klippel@synthio.com; Author author@noreply.github.com Subject: Re: [emailhippo/email-verify-api-v3-client-wrapper] disable stylecop! (#1)

We could do something like thishttps://github.com/binarymash/responses/issues/20.

Any good?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHubhttps://github.com/emailhippo/email-verify-api-v3-client-wrapper/issues/1#issuecomment-304311564, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AQ1LSZFzqMmUm-85YWtMru7OT4E_h-DMks5r9u6JgaJpZM4Nmilu.

emh-rowland-oconnor commented 7 years ago

Thank you.

Resolved in 7f778f4.