Depends on whether they have personality disorders.
Why Code Snobs Are Invaluable
51–56 of 56 posts
Re: Why Code Snobs Are Invaluable
#52Earlier quoted context omitted.
What about the colleague's who have successfully enshrined non-idiomatic variable naming and space rules in a project? They seem to have just as much of this argument on their side, as far as consistency and such. Yet I actually loathe the decisions, as it causes a ton of friction with standard tools.
Everything causes friction with respect to something. So you have to examine the merits of the argument. I, for instance, loathe the prescription that the names of .NET interfaces begin with "I". This is because I realized that once you understand the difference between a “class” and a “type”, then it becomes obvious that everything is an interface (abstraction is just naming things). But, the .NET style guide hinder…
More often than not, Abstract Classes, and Interfaces in .Net are more for testability, or code generation than they are actually needed for a working system. I'm not saying they are bad, as I actually like WCF (using a DI framework with convention, not the XML config hell) as well as a lot of the Entity Framework bits.
That said, the more I work with components and smaller services in node.js, the more I enjoy it. It's nice to be able to write meaningful unit tests without several layers of indirection just to be able to write tests.
Re: Why Code Snobs Are Invaluable
#53What about type theory weenies? The title is also a little link-baity. The person commenting on his pull request was not being a snob. He was making sure there was architectural coherence across the board. When codebases grow large having an idea of the overall architecture becomes an invaluable resource and the more consistent the codebase the easier it is to make sense of the architecture.
> What about type theory weenies?
Are we first graders?
Re: Why Code Snobs Are Invaluable
#54OT but when do you need singletons in JavaScript?
Pretty much the same as in any other language. When you want to guarantee that there will only ever be one instance of an object.
It is a useful pattern for managing data synchronization (ie, if I only ever have one instance of a User, I know another instance won't mess up its state accidentally.)
Re: Why Code Snobs Are Invaluable
#55Singletons were perhaps the worst possible example of code snobbery: code snobs ( real code snobs, as in "no true code snob") typically detest the singleton pattern as less maintainable, less testable, and less flexible than dependency injection.
In the author's example it's about internal consistency , a bunch of other similar items are already singletons. Better a consistent-but-suboptimal architecture than a random grab bag of varying quality.
A journey of a thousand miles starts with the first step. If you're committed to code quality, existing low quality code should not prevent you from doing the right thing with new code; on the contrary, doing the right thing with new code will free you to refactor or update the old code to be cleaner.
Re: Why Code Snobs Are Invaluable
#56Earlier quoted context omitted.
In the author's example it's about internal consistency , a bunch of other similar items are already singletons. Better a consistent-but-suboptimal architecture than a random grab bag of varying quality.
A journey of a thousand miles starts with the first step. If you're committed to code quality, existing low quality code should not prevent you from doing the right thing with new code; on the contrary, doing the right thing with new code will free you to refactor or update the old code to be cleaner.
Again, I refer you back to the original scenario: The inconsistency is presented as accidental or unintentional, not as the first step in a cohesive long-range plan to refactor the codebase.