Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

What is “good taste” in software engineering?

seangoedecke.com

Post reply on HN
Print view View original

101–110 of 245 posts

Re: What is “good taste” in software engineering?

#101

Post by imiric »

vendiddy wrote: post #93
imiric wrote: post #78

Earlier quoted context omitted.

> 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 optimizi…

> 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?

You're misunderstanding. Code is not broken up because it's "long". It's broken up because it is difficult to comprehend and maintain, and its length is one criterion that might signal that to be the case. Another sign is cyclomatic complexity, which is another arbitrary number left for teams to decide how to use best.

The main topic, and why it is so widely argued, is that readability and maintainability are entirely subjective concepts that are impossible to quantify. This is why we need some specific guidelines that could point us in certain directions.

This doesn't mean that these guidelines should be strictly enforced. I've often decided to silence linters that warn me about long functions or high cyclomatic complexity, if to me the function is readable enough, and breaking it up would be more problematic. This is open to interpretation and debate during code reviews, but it doesn't mean that these are useless signals that developers should ignore altogether.

Re: What is “good taste” in software engineering?

#102

Post by maccard »

medstrom wrote: post #73
OtherShrezzing wrote: post #6

> One interesting consequence of this is that engineers with bad taste are like broken compasses. If you’re in the right spot, a broken compass will still point north. It’s only when you start moving around that the broken compass will steer you wrong. Likewise, many engineers with bad taste can be quite effective in the particular niche where their preferences line up with what the project needs. This paragraph real…

Can you paint an example of a "partially broken compass" engineer?

I've worked with engineers who can happily write greenfield code that passes the spec, but fails on any inputs that are not clearly defined as valid. In an effort to fix this, they add layers and layers and layers of complexity and edge cases to the app logic, and intermix the actual app logic with handling invalid input. something like

    func isEven(s string) bool {
        num, _ := strconv.Atoi(s)
        return num % 2 == 0
    }
becomes:

    func isEven(s string) (string, error) {
        f, err := strconv.ParseFloat(s, 64)

        if err != nil {
            return "invalid", err
        }
        num := int(f)
        if num%2 == 0 {
            return "even", nil
        }
        else if num % 2 != 0 {
            return "odd", nil
        }
        return "invalid", nil
    }
Which is.... technically correct, instead of

    func isEven(num int) bool {
        return num % 2 == 0
    }
    func isEvenSafe(s string) (bool, error) {
        num, err := strconv.Atoi(s)
        if err != nil {
            return false, err
        }
        return isEven(num), nil
    }

Re: What is “good taste” in software engineering?

#103

Post by eowyn »

yegle wrote: post #63

How to distinguish "good taste" vs "opinionated" though? If you can articulate why certain code is better with convincing justifications, I would say that's "good taste". Coding styles are often examples of these. But if you can't articulate or don't have a convincing reasoning for preferring certain coding patterns, isn't it just "opinionated"?

I think good taste and opinionated aren't quite the same thing but you do need to have some opinions to have good taste, it's almost like a precursor. Good taste then comes from knowing which of your opinions you're optimising for in the current situation and which of your opinions are either not relevant or perhaps the situation is not suitable or ready for them.

Re: What is “good taste” in software engineering?

#104

Post by eowyn »

mrkeen wrote: post #83
8-prime wrote: post #52

Earlier quoted context omitted.

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 th…

> Even the best actionable principles can be incorrect given a certain set of circumstances. If they are principles, the discussion around whether to apply them can at least be fruitful. "Taste" is bound to devolve into "I like this" vs "I like that". I don't buy into the "everything has its upsides and its downsides" advice given in the article for the same reason. It's a useless truism. It's a taste:- I have 1 new…

> "Taste" is bound to devolve into "I like this" vs "I like that" My read of the article was less "I like this" and more "I've seen xx work best in a situation like this where we're optimising for yy but if we're optimising for zz then something else would be more suitable"

It's less about what you like or dislike and more about aligning a collection of practices you've seen work well to the situation and constraints, which is why variety of experience helps

I'm not sure why stirring up shit or inflaming egos would necessarily happen with such conversations. Skilled engineers often start a solution proposal by explicitly outlining what they are optimising for, known limitations etc which all help create a baseline to describe "taste"

Re: What is “good taste” in software engineering?

#105

Post by mojuba »

pbalcer wrote: post #59
mojuba wrote: post #20

> 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…

I didn't say readability is subjective. I'm just asking, when someone says "code should be readable" without any clarifications, what does it really mean?

Big companies may actually have an answer to that: "since we require at least 2 years of experience in the area from new hires, all code should be readable at that level".

However startups may prioritize something else over readability at that level, for example: move fast, produce the most minimalist code that would be easy to maintain for people like you.

My point being, "code should be readable" should always come at least with a footnote that defines the context.

Re: What is “good taste” in software engineering?

#106

Post by skydhash »

Yoric wrote: post #61
zx8080 wrote: post #23

Earlier quoted context omitted.

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.

I'll have to disagree. Developers coming from functional programming and developers coming from C programming, for instance, have very different definitions of "readable", and neither is obviously wrong. Similarly, developers used to channel-based, async-based or mutex-based concurrent programming will all have very different criteria for "readable" code, again none of them obviously wrong.

Those are just paradigms, ways of solving problems. There’s a difference between familiarity and readability. Sometimes you have to learn stuff before understanding them. Readability is how easy it is to do that, given familiarity with the base concepts that the code use.

Re: What is “good taste” in software engineering?

#107

Post by autonomousErwin »

actionfromafar wrote: post #7
lofties wrote: post #5

Good taste, is what I like and advocate for. Bad taste, is the opposite.

You never advocated for something you agree is a huge kludge? :)

I think first step of having good taste is admitting that you probably have bad taste

Re: What is “good taste” in software engineering?

#108

Post by skydhash »

maccard wrote: post #102
medstrom wrote: post #73

Earlier quoted context omitted.

Can you paint an example of a "partially broken compass" engineer?

I've worked with engineers who can happily write greenfield code that passes the spec, but fails on any inputs that are not clearly defined as valid. In an effort to fix this, they add layers and layers and layers of complexity and edge cases to the app logic, and intermix the actual app logic with handling invalid input. something like func isEven(s string) bool { num, _ := strconv.Atoi(s) return num % 2 == 0 } beco…

Also the ones that can’t understand abstraction and are happy copy-pasters. Or the ones familiar with some paradigms (ex OOP) that brings it everywhere.

There are a lot of ways to accumulate tech debt so fast you’d think you’re in a code casino.

Re: What is “good taste” in software engineering?

#109

Post by hhjinks »

kaffekaka wrote: post #90
PickledChris wrote: post #87

Earlier quoted context omitted.

I see this argument pattern a lot, so looked into what the name is. Apparently it's called Sorites paradox: https://en.wikipedia.org/wiki/Sorites_paradox or the "continuum fallacy" in which something that's continuous is dismissed as not existing because we can't divide it into clear categories.

Did someone claim readability does not exist?

> Readability is a non-concept really

Yes.

Re: What is “good taste” in software engineering?

#110

Post by mojuba »

hhjinks wrote: post #109
kaffekaka wrote: post #90

Earlier quoted context omitted.

Did someone claim readability does not exist?

> Readability is a non-concept really Yes.

Readability without a clarification is a non-concept. You can't say "X should be readable" without giving some context and without clarifying who you are targeting. "Code should be readable" is a non-statement, yes.
Post reply on HN