21–30 of 56 posts
What is the goal of this software? Ship now? MVP?
Are we trying to polish the software? Or just get it to work? Is it a prototype?
Some thoughts to take into consideration.
It depends what you mean by code snob... I've had a dev replace large section of my code with "cleaner" code that didn't work in all cases, comment out the failing tests, then push that. Some people are convinced that making components isolated and aesthetically clean is more important than making them functional.
This is really interesting. Can you elaborate on what they might have been thinking when commenting out those tests? (which seems pretty blatant). Were the tests commented as to what they were doing, and obviously were important, relevant, and should have passed?
My impression is that when you go to a higher (cleaner) level of abstraction, you lose some immediate abilities. For example if you move a global variable without classes to a static variable in the class it really belongs with (after writing that class), you can never (by doing that) enable additional functionality over having it be a global variable. But the variable might no longer be accessible at some point, perhaps if a different base class has a static member whose initialization depends on another one already being initialized - that sort of thing.
which is the whole point. you are applying a new abstraction, and in the new abstraction they're not global variables but properties of a class. Perhaps some tests become irrelevant or need to be rewritten.
So, you could have some test fail as written, because you've moved to a higher level of abstraction. This makes me wonder what the exact tests were in the case you refer to...
Consider a colleague who constantly objects to non-idiomatic variable name casing (snake_case_in_ruby, camelCaseInJavaScript, dashes-in-lisp, scheme-predicates?, &c.) When you first get a comment like this, it may feel like friction. After all, the code works. The cost of holding up a deploy and changing your code feels all out of proportion to the benefit. And it’s easy to extrapolate this: “If I get this objection…
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.
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 hinders that understanding since it enjoins you to focus on the little things (classes and interfaces) instead of the big things (types)[1].
So, “code snobbery” is about figuring out what you really want, and then creating cognitive affordances (or eliminating cognitive hinderances) with respect to that.
[1] This is especially apparent when you consider how interfaces and classes are defined in F#.
It depends a lot on your mentality toward writing code. I find matching the long/short-termness of engineering practice to the overall mentality of the organization results in the least friction. Concrete example: if you're building a system to last 5-10 years, act like it. Spend time getting the architecture, the variable names, and the module structure correct. But realize not everything must be built to last. I re…
Earlier 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.
The norm seems to be: Conform to what's currently in the code. Whether it's variable names, your brace style or indenting lengths, it doesn't matter if you think your way is the best, what matters is fitting in with the existing (shared) codebase so it's readable to everyone who has been working on it for the last 5 years. Same is true for non-style things. If your project is 100K lines of 1998-era "C-with-classes" C…
Singletons 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.
Over reliance on singletons can indeed be less maintainable, less testable, and less flexible than dependency injection. However sometimes a singleton is in fact more maintainable and improves the code massively. Nor do they have to be less testable when implemented well. None of which detracts from the article which is about consistency in the code base. A knew jerk reaction to the singleton completely misses the po…
It depends what you mean by code snob... I've had a dev replace large section of my code with "cleaner" code that didn't work in all cases, comment out the failing tests, then push that. Some people are convinced that making components isolated and aesthetically clean is more important than making them functional.
Earlier quoted context omitted.
Over reliance on singletons can indeed be less maintainable, less testable, and less flexible than dependency injection. However sometimes a singleton is in fact more maintainable and improves the code massively. Nor do they have to be less testable when implemented well. None of which detracts from the article which is about consistency in the code base. A knew jerk reaction to the singleton completely misses the po…
I totally agree that the singleton detail is beside the article's point, but what is the modern case for singletons? It seems like singletons are now considered a synonym for global variables. What other purpose do they serve?
Consider a colleague who constantly objects to non-idiomatic variable name casing (snake_case_in_ruby, camelCaseInJavaScript, dashes-in-lisp, scheme-predicates?, &c.) When you first get a comment like this, it may feel like friction. After all, the code works. The cost of holding up a deploy and changing your code feels all out of proportion to the benefit. And it’s easy to extrapolate this: “If I get this objection…
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.