Skills Poor Programmers Lack

Re:Skills Poor Programmers Lack by onion2k on Sunday July 21, 2019 @12:58PM (#20492266)

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 good programmer and a bad programmer is that the good one writes working, readable, human understandable code that does the job it's supposed to do. That's it. Someone who writes code that's shorter without being more understandable, or faster, or significantly more efficient, isn't better.

[ Parent | on HN ]

Re:Skills Poor Programmers Lack by nicoburns on Sunday July 21, 2019 @03:11PM (#20493097)

I've worked on codebases where people consistently did things in 3-6 lines that could have been done in one (without it being an overly complex line).

It was massively detrimental to readability, because it meant what should have been a 5 or 6 line function suddenly became 20 or 30 lines. A 20 line function is suddenly 100 lines. And you had to wade through each part to work out what it was doing rather than just glancing at it and it being obvious...

[ Parent | on HN ]

Re:Skills Poor Programmers Lack by userbinator on Sunday July 21, 2019 @06:04PM (#20493949)

A 20 line function is suddenly 100 lines.

...and what's worse, that then gets broken up into smaller functions containing equally trivial-but-bloated code, and now you need to jump around even more to understand something that's actually very simple.

At the extreme end of the terseness scale are the APL-family languages, and the people who work with them have no problems reading or writing code like this:

https://code.jsoftware.com/wiki/Essays/Incunabulum

I think it really says something about the state of software development when you consider that a not-insignificant number of people who are perfectly fine with that level of density (and they are making $$$$), and yet there are others who will complain that even K&R's style is not verbose enough. IMHO it's a matter of education and attitude.

[ Parent | on HN ]

Re:Skills Poor Programmers Lack by agumonkey on Sunday July 21, 2019 @01:19PM (#20492401)

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.

[ Parent | on HN ]

Re:Skills Poor Programmers Lack by injb on Sunday July 21, 2019 @01:34PM (#20492499)

That's not really a fair comparison. The first example is a fairly natural way that a reasonable person could model the logic in their head. Knowing that your programming language provides a more concise way is an optimization. A basic one admittedly, but a mere optimization nonetheless.

In contrast, your example is kind of the opposite situation - it's an example of forgoing the most natural, human representation in favour of a highly Python-specific one. In other words, the first one happens when you know the abstract logic, but don't know your tools very well; your example happens when you know lots of useless details about the tool but you're struggling with the abstract logic.

Actually, the example from the article suggests to me that the author misunderstands what I regard as the most fundamental programming skill: knowing the precedence of correctness over all other concerns, including efficiency. It's better to attach the right parts together badly than to attach the wrong parts like a pro.

[ Parent | on HN ]