41–50 of 56 posts
The advantage is that tools reject the pull request, and not a person. It doesn't harm ego to be rejected by a tool.
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.
Well it would likely be better to have a discussion about it then? Instead of a brewing conflict among members of the team? It's also where leadership comes in. Someone needs to make a decision and guide the team in a particular direction. The most important thing is not that he/she chooses the "best" way (implying one engineer was "wrong") but rather simply that a way is chosen and everyone follows it.
This (sw design) is a multidimensional optimization problem with a somewhat vague cost function. But argmin on the # of bugs and argmax on feature completion is far more important than everyone following some random standard.
In OP's example, the singleton is a design pattern, not a coding standard. It should be used if it is applicable to the scenario, as it seem like it was.
Other people here in the comments are talking about "code snobs" as people that like to follow certain coding standards. IMHO, coding standards should be defined by the entire team and everyone has to follow. There is no way to have a consistent code without that, so it is not about being snob, it is about having a consistent codebase.
Now, if there are coding standards or an architecture defined but someone wants to use a different one because they want to be snob about it, then you have a problem. If there is a standard, let's say a naming convention as a simple example, and someone wants to change it at some point, you either have to change everything else to follow the same new standard, or don't start a new standard at all. Otherwise you are not resolving the original issue, you are simply making it worts by having more than one standard in your code base.
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…
But your thinking like a programmer. Some times it is also valuable to think like a business. 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 could also be a double-edged sword. I've seen it happen more times than I can remember. Management sets a clear deadline, we rush the code to get it done by its due date. Then the product sits there for months doing nothing while we're in between projects wasting time away. Half a year down the road we get asked for support because some things broke which would've been working fine had we taken the proper time to…
This seems to be so common. Almost every project seems to break or have issues at some point and the excuse is always the same: oh we didn't have time to do it properly. It makes me wonder if that is indeed always the case. This leads to a question... are there projects that are done in enough time so that they won't break?
Earlier quoted context omitted.
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?
I wrote a singleton the other day. Using Java, I had a static utility class that had a function that I wanted to memoize. So I put a static HashMap in the class to do the lookups. There's no reason to have multiple copies, and it's easy to instantiate it only if it is needed.
Earlier quoted context omitted.
I wrote a singleton the other day. Using Java, I had a static utility class that had a function that I wanted to memoize. So I put a static HashMap in the class to do the lookups. There's no reason to have multiple copies, and it's easy to instantiate it only if it is needed.
That's reasonable, but it seems to be equivalent to creating a top-level function and associated global variable in other languages. Java's prohibition of those constructs necessitated the class wrapper, but doesn't appear to provide any benefits over another more generalizable method, namespacing.
I suspect dependency injection has the same problem: you could achieve the same results in a non-object-oriented language.
Earlier quoted context omitted.
It could also be a double-edged sword. I've seen it happen more times than I can remember. Management sets a clear deadline, we rush the code to get it done by its due date. Then the product sits there for months doing nothing while we're in between projects wasting time away. Half a year down the road we get asked for support because some things broke which would've been working fine had we taken the proper time to…
> Half a year down the road we get asked for support because some things broke which would've been working fine had we taken the proper time to built them. This seems to be so common. Almost every project seems to break or have issues at some point and the excuse is always the same: oh we didn't have time to do it properly. It makes me wonder if that is indeed always the case. This leads to a question... are there pr…
But I agree this isn't the norm.
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…
That usage of "idiomatic" feels idiomatic to me. ;)
(I'd usually bite my tongue about such things, but your nic is picks_at_nits, and the thread is about the virtues of being pedantic...)
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?
It enabled us to decouple some code deep down in our architecture and enforce some constraints around the use of this particular piece.
When you actually need a singleton it's best to use one and call it out as such so people know what they are dealing with. Dependency injection will often be passing around a singleton everywhere without people being aware that it's a singleton and all that that means.