This is exactly what bad taste is. Not one mention of if the software is actually 'good' to use for the end user.
What is “good taste” in software engineering?
51–60 of 245 posts
Re: What is “good taste” in software engineering?
#52"Good taste" is just advice or guidance that you haven't thought through enough to turn into actionable principles. Compare: * I apply the dependency inversion principle to keep my code testable * I minimise the scope and mutability of all my variables With: * These methods do what they say they do * This code is good because it's declarative * These functions have the right number of lines
I may be misunderstanding what you're trying to say, but I feel like this still suffers from one of the mentioned issues - situationality.
Even the best actionable principles can be incorrect given a certain set of circumstances. If in those cases you choose to uphold your priciples, rather than choosing what is "right" for the project you would fall into the camp of "bad taste".
That is at least how I interpreted the article.
Re: What is “good taste” in software engineering?
#53Good taste is writing code that looks so simple, everyone else says "pshaw, anyone could have written that!"
> everyone else says "pshaw, anyone could have written that!" it really depends on the problem domain tho, doesnt it? Would you call the fast inverse square root[0] code good taste? [0] https://en.wikipedia.org/wiki/Fast_inverse_square_root#Overv...
One is an algorithm, a purely technical solution. The other is the way code is structured in an application.
Re: What is “good taste” in software engineering?
#54> Is the software easy to take in at a glance and to onboard new engineers to? This is not as easy as it sounds. Who are those "new engineers", juniors? 10 years of experience? 30 years? What's your requirement? "Readability" is such a wildcard, with a whole range of acceptable levels from zero to infinity. Readability is a non-concept really. Maxwell's famous equations are readable to some and absolutely impenetrabl…
Theere are two quite a widespread classes of not readable code: Some code is not readable by _anyone_. That's not readable code. Some code is readable by its author only (be it AI or a human). That's also not readable one. Saying readability is not a concept is really strange.
Readability to a certain degree is heavily influenced to the reader's experience and familiarity.
If somebody has spent lots of time in specific patterns he/she'll find them natural to read and mentally process.
To others, they'll be unreadable.
Re: What is “good taste” in software engineering?
#55Id settle for "common sense" - seems to lack in a lot of codebases
Re: What is “good taste” in software engineering?
#56[dead]
Re: What is “good taste” in software engineering?
#57I heard readability is a touchy subject since some people say having your code easy to read would make replacing you easier.
If you write your code such that you are hard to replace, because noone else would be able to understand what you were doing, I would consider that to be "bad taste" and "bad form".
Re: What is “good taste” in software engineering?
#58> Is the software easy to take in at a glance and to onboard new engineers to? This is not as easy as it sounds. Who are those "new engineers", juniors? 10 years of experience? 30 years? What's your requirement? "Readability" is such a wildcard, with a whole range of acceptable levels from zero to infinity. Readability is a non-concept really. Maxwell's famous equations are readable to some and absolutely impenetrabl…
Call me naive, but I would presume that even a junior, once they start working at a company, should be familiar enough with a language that they know all the basic syntax, idioms etc. Still, even if they are, over-using some language features will make your code less readable (to anyone). E.g. some will prefer good ol' if/else to the notorious ternary operator and its many descendants. But that brings us back to your own personal taste...
Re: What is “good taste” in software engineering?
#59> Is the software easy to take in at a glance and to onboard new engineers to? This is not as easy as it sounds. Who are those "new engineers", juniors? 10 years of experience? 30 years? What's your requirement? "Readability" is such a wildcard, with a whole range of acceptable levels from zero to infinity. Readability is a non-concept really. Maxwell's famous equations are readable to some and absolutely impenetrabl…
Readable code is code that has empathy for the reader and tries to minimize the cognitive load of interpreting it. That's one of the goals of abstraction layers and design patterns.
Yes, it's all subjective, and depends on the reader's expertise and existing familiarity with the codebase. But arguing that code readability isn't at thing, because it's subjective, is an absurd take. Would you claim that Joyce's Ulysses is equally readable as Seuss's The Cat in the Hat?
Re: What is “good taste” in software engineering?
#60> 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…
Can you provide examples of software that should have literally been a spreadsheet or an ETL? Not to call you out specifically but this feels like "I could have written that in a weekend". Personally whenever I have felt that way about a project it turned out I was just missing 95% of the business context/domain knowledge (part of the reason I think rewrites are a bad idea - chesterton's fence).
I can give you one - a billing system with reporting features that suck dreadfully compared to what can be done with a spreadsheet. Why not "just" let the user download a CSV and then do whatever they want with it?
I was working on this project and I kept suggesting it. It was seen as inferior and yet the system we were going to produce was far inferior in every way.