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

Skills Poor Programmers Lack

justinmeiners.github.io

Post reply on HN
Print view View original

41–50 of 211 posts

Re: Skills Poor Programmers Lack

#41

Post by wisienkas »

transreal wrote: post #9
cgriswald wrote: post #4

> You may have seen code which misunderstands how expressions work: > if isDelivered and isNotified: isDone = True else: isDone = false; > Instead of: > isDone = isDelivered and isNotified Are people actually finding code like this in professional work or is this just an example? I'm self-taught and know I've got some gaps, but this example is so fundamental I find it shocking.

I see this in professional work. The former reads more like English, and so there feels like there is an argument to be made that it is more readable, and also an argument that "the compiler will optimize it for you anyway".

and you question yourself if it was better to pack that readability into a function or not.

Also why would anyone store a boolean named isDone rather than just returning it as the contract of the function

Re: Skills Poor Programmers Lack

#42

Post by Biganon »

transreal wrote: post #9
cgriswald wrote: post #4

> You may have seen code which misunderstands how expressions work: > if isDelivered and isNotified: isDone = True else: isDone = false; > Instead of: > isDone = isDelivered and isNotified Are people actually finding code like this in professional work or is this just an example? I'm self-taught and know I've got some gaps, but this example is so fundamental I find it shocking.

I see this in professional work. The former reads more like English, and so there feels like there is an argument to be made that it is more readable, and also an argument that "the compiler will optimize it for you anyway".

Are they wrong? To me, the long version is valid precisely because it is explicit (more to me than the short version), and will be optimized

Re: Skills Poor Programmers Lack

#43

Post by munchbunny »

thecleaner wrote: post #6
cgriswald wrote: post #4

> You may have seen code which misunderstands how expressions work: > if isDelivered and isNotified: isDone = True else: isDone = false; > Instead of: > isDone = isDelivered and isNotified Are people actually finding code like this in professional work or is this just an example? I'm self-taught and know I've got some gaps, but this example is so fundamental I find it shocking.

Can confirm. Made this mistake myself actually. However to make a contradictory point apart from being better style what are the other advantages of not using if statements and use boolean algebra instead ?

Verbosity tends to hurt readability, but trying to cram too much into one line tends to create something where nobody remembers how it works either. So it's really a judgement call on which approach reads more naturally.

My personal rule of thumb on this is that single statement conditions aka "a = {condition}" should be using only "and" operators or only "or" operators and should generally avoid nesting unless there's a clear explanatory comment. So "a and b and c and d" is ok but "a and b or c and d" is sketchy. The reason is that "all" and "any" are idiomatic, but "some" takes more mental work to parse.

Also it's always useful to keep in the back of your mind:

!(a || b) == !a && !b

Whenever I spot either side of the equation in a condition, I stop and consider whether the alternate formulation would be more readable.

Re: Skills Poor Programmers Lack

#44

Post by UnpossibleJim »

humanrebar wrote: post #25

Most programmers do not follow the Golden Rule, which is to write code you'd like to maintain with minimal training. It's a principle, but there are various skills involved in doing it successfully, including writing, automation, design, seeking quality peer review, and a few other things. Similarly, writing code that can be deleted is an important skill. Using "good design" and "knowing your language" are fairly neb…

While I applaud this and would love this rule to be in production, it tends to go against (the majority of) marketing's golden rule of, "I need this done in an unreasonable amount of time with unreasonable requests on functionality" and a management structure that tends to only flex to its subordinates instead of other departments, like they're supposed to.... though, I might be jaded =) I have seen a few very good managers/CTO's in my time and have left companies when they were forced out.

Re: Skills Poor Programmers Lack

#45

Post by craigsmansion »

The question is: if making a schema to distinguish between "good" and "poor/naive", can one do so whilst keeping biases in check, viz. without inadvertently putting one's own understanding (or unknown lack of understanding) in the "good" camp?

Unless you're EWD, the answer is "no". No you cannot.

Re: Skills Poor Programmers Lack

#46

Post by drchewbacca »

cgriswald wrote: post #4

> You may have seen code which misunderstands how expressions work: > if isDelivered and isNotified: isDone = True else: isDone = false; > Instead of: > isDone = isDelivered and isNotified Are people actually finding code like this in professional work or is this just an example? I'm self-taught and know I've got some gaps, but this example is so fundamental I find it shocking.

Is anyone willing to explain the second line? I get the first means "if isDelivered and isNotified are both true then set isDone to True, if not set it to false". However I've never seen a variable being set "isDone = isDelivered" as part of a logical test.

Personally I think programmers who are "too clever" are cancer inside a codebase. Sure you saved a bunch of keystrokes but your code golf has locked the code forever unless someone is willing to rewrite it. This is not a bad example but in general I think people who strive to do things in less characters are highly problematic.

Re: Skills Poor Programmers Lack

#47

Post by ALittleLight »

dpeterson wrote: post #12

This article says more to me that the author(s) are inexperienced themselves rather than shed any light on the practice of software development. I'm imagining some recent boot camp graduates attempting to conflate their months of programming experience into something more than that. "Hey old dudes in company I just joined, I found some things I think are basic so I'm going to write an article to indirectly shame you…

I think it would be more useful if you could provide specific criticism - i.e what you think is wrong and why. Your comment seems rather general. I could imagine copying and pasting it beneath a wide variety of articles and it would be equally applicable.

Re: Skills Poor Programmers Lack

#48

Post by itronitron »

leetrout wrote: post #8
cgriswald wrote: post #4

> You may have seen code which misunderstands how expressions work: > if isDelivered and isNotified: isDone = True else: isDone = false; > Instead of: > isDone = isDelivered and isNotified Are people actually finding code like this in professional work or is this just an example? I'm self-taught and know I've got some gaps, but this example is so fundamental I find it shocking.

Yes. And a coworker wrote his own string join method in Python (and was mad he wasn’t a senior engineer).

during his job interview or after he was hired? (jk)

Re: Skills Poor Programmers Lack

#49

Post by torgard »

humanrebar wrote: post #15
dymk wrote: post #7

Earlier quoted context omitted.

Oh, yes, I saw stuff like this in Big Blue Company's source control. At a different company, I found stuff like: ZERO_INDEX = 0 ONE_INDEX = 1 return arr[ZERO_INDEX]

That's usually a sign of overly aggressive linters and static analyzers. They probably got a "no magic numbers" diagnostic. The solution to this problem is to add some sort of `NOLINT` comment to that line or, if possible, the comment that turns off that particular check. Then you link to the design document describing what "arr" is and how its interface involves accessing indices 0 and 1. Or you could wrap "arr" up…

It took me a while to understand the whole "no magic numbers" thing.

I was basically just told that most (if not all) numbers should be stored in constants. So I just added int twentyFive and stuff, and it annoyed me, but my teacher was happy.

Much later, I realized the missing part: Name the constant not what it is, but rather what it does. So int rightBoundary instead of twentyFive, and the code suddenly becomes much more readable.

Re: Skills Poor Programmers Lack

#50

Post by agumonkey »

onion2k wrote: post #21
cgriswald wrote: post #4

> You may have seen code which misunderstands how expressions work: > if isDelivered and isNotified: isDone = True else: isDone = false; > Instead of: > isDone = isDelivered and isNotified Are people actually finding code like this in professional work or is this just an example? I'm self-taught and know I've got some gaps, but this example is so fundamental I find it shocking.

In my 20something years of writing software for a living I've seen both. And I find it very hard to care which one someone on my team uses. It's not something fundamental. Both lines work perfectly well. They do the same thing. The second is more concise and 'better', but if the only improvement you can suggest in a code review is something like shortening a line then the code is basically fine. A difference between…

You have a point but the issue with redundant boolean code like above is that it shows a lack of metalevel thinking.

kinda like this python exagerated code:

    def sum(a,b):
        return operators.add(a,b)
It can lead to bloat.
Post reply on HN