Tabs instead of spaces.
Spaces have won already. It is the default setting across code editors now.
If your code editor told you to use PHP, would you?
What is “good taste” in software engineering?
91–100 of 245 posts
Re: What is “good taste” in software engineering?
#92Tabs instead of spaces.
Spaces have won already. It is the default setting across code editors now.
Elastic tabstops are good taste. Tabs should tabulate.
But limited editor support, and some implementations have poor performance.
Re: What is “good taste” in software engineering?
#93Earlier quoted context omitted.
You break up things when it makes sense, not for the sake of it. Having to jump out of the code you're reading comes with its own downsides and tends to compromise maintainability where you are increasing the shallowness of your code (same functionality, but higher api surface). You break up things when there are benefits to breaking them and Unix provides a very sensible reference to this topic where plenty of sysca…
> You break up things when it makes sense, not for the sake of it. I never claimed otherwise. > Having to jump out of the code you're reading comes with its own downsides and tends to compromise maintainability where you are increasing the shallowness of your code (higher api surface). I don't buy this argument. The code you're reading should do one thing according to what it says on the tin (the function name). When…
If you are breaking something up for "long" and "short" you're optimizing for the wrong thing. You don't care about code being short for its own sake or long for its own sake right?
Ultimately, you're going to revisit this code to make the change after some time passes. Is it easy to follow the code and make the change without making mistakes? Is it easy for someone else on the team to do the same?
Sometimes optimizing for "easy to understand and change" means breaking something apart. Sometimes it means combining things. I've read that John Carmack would frequently inline functions because it was too hard to follow.
So, rather than whether something is big or too small, I would ask whether it would be easy to understand/change when coming back to it after a few months.
Put another way: why not optimize for the actual thing you care about rather than an intermediate metric like LOC?
Re: What is “good taste” in software engineering?
#94A: Experience
Have your 10 mins back.
Re: What is “good taste” in software engineering?
#95I find that when people value vanity or discussions of how to proceed their confidence is low. These are red flags for me. It’s assumed that if you aren’t a junior you should be able to immediately reason multiple original routes to the goal.
I suppose the most important matter of “taste” is how deterministic the flow control is by just reading the code. It doesn’t have to be pretty. When this is absent I know the author values something other than maintenance or extension. When it’s hidden behind cultural conventions, like a framework, I know the author values those learned conventions more than a utility goal or objective criteria.
Since these observations reflect behavior they apply equally to many other non-code contexts in the real world.
Re: What is “good taste” in software engineering?
#96Good taste is writing code that looks so simple, everyone else says "pshaw, anyone could have written that!"
And the tragedy is that authors of such code often (usually?) don't receive recognition for saving time and effort on others' part by following KISS principles. For whatever reason its apparently opaque to others. And so there are entire jobs or even teams in the tech industry whose purpose is to work with and/or maintain systems that have needless complexity.
Re: What is “good taste” in software engineering?
#97> In my view, your engineering taste is composed of the set of engineering values you find most important. For instance: Strange how absent the customer or underlying business always is in this discussion. I've seen a LOT of software that could have literally just been a spreadsheet on a file share or a simple SQL ETL job. When reviewing the actual business requirements, we will often find that we don't even need a g…
I agree that the customer / business focus is often very lacking. Sometimes because engineering is put too much into focus, but very often because of politics. At the same time it's not an easy thing to do. The "business" is usually quite bad at verbalizing their needs and requirements, especially at the level of detail that engineering requires.
Having done at least one migration from "could have literally just been a spreadsheet" applications into proper applications, I'm very careful with recommending spreadsheets. It's great how flexible they are, but that's also their major down side. If you want to enforce anything within a spreadsheet, you have few options and it's very easy for something to break. For example someone deleting a formula, a formula not including the full range, or copy & pasting breaking the references. Not to mention the performance issues you'll run into once you've collected a few rows.
Re: What is “good taste” in software engineering?
#98> In other words, our disagreement comes down to a difference in values.
I don't think that's the whole story.
Us humans are not very good at recognizing it, but we all model and understand the world slightly differently.
So that even if you fundamentally agree with someone's values, you might prefer other code to that person because it fits better in the way a problem is modelled in your brain than in someone else's.
Re: What is “good taste” in software engineering?
#99I would say limiting the braggadocio is important to "good taste" as well. I interviewed once for a dev role on the email team for a very large free software company you've heard of. The team's egos were so large I could hardly fit in the room. "Oh! I see you wrote the control system for a nuclear power plant. That's cute, I once inverted a tree data structure!" or "I see you wrote the modular exponentiator that was…
+1 to limiting braggadocio. Maintaining code written by someone with humility, and consideration for the subsequent maintainer (including themself, as they don't assume they're super(wo)man and will understand their own code immediately after time away) is much easier than code written by someone with a large ego who likely thinks anyone who doesn't understand their code is "dumb" / "a wimp" etc
Re: What is “good taste” in software engineering?
#100Lecturing on "good taste" is a huge red flag for narcissism. "Taste" implies subjectivity. Pairing it with "good" is presupposing something along the lines of "my subjective evaluation of things is superior to yours", or "my subjective choices are superior to yours".
This is something I wrestle with. Objectively, it'd seem true that say, a Henry Moore sculpture is of "better taste" than Disneyland. ;) But I 100% wouldn't wanna criticise anyone who preferred Disneyland. Its up to them, they don't have "poor taste" for preferring that... its arrogant indeed to make such a judgement, but then again... surely.. Henry Moore, Disneyland... there's no comparison? ;) so I go around in circles... ;)