Hacker News Reader

> Practice, practice, practice is not necessarily good advice if you don't know what you're doing.

Your example is good about learning good program structure; that can save you a lot of time. You can only learn so much that way though. Sometimes you just have to make mistakes.

I've written a lot of code that is bad. But if I hadn't written that code and I was tasked to do again I'd do it the same way because there is no other experience to tell me not to do that. My sum knowledge of programming is everything I learned from school and from reading -- but the majority comes from actually writing a whole lot of crap.

It's interesting but in my experience:

> Subroutines must have one entry point and one exit point, and accomplish one task.

My subroutines almost always exit early at the top if any pre-conditions fail to be met. This is much better than a ton of nested if statement for each pre-condition. But in general it's best not to exit somewhere in the middle.

> Add lots of comments in your code to help others or even yourself in case you forget what your thinking was.

In practice, comments are pretty hard to maintain. I usually ask new applicants how they ensure a project can easily be passed off to others and if they just answer comments then that's generally a bad sign. Good hires will often laugh when mentioning comments and then describe other things like good naming, etc.

> - Subroutines must have one entry point and one exit point, and accomplish one task.

Sometimes code is much cleaner if you exit a method or a function early. Especially in languages with automatic memory management where you don't need to concern yourself about leaks so much.

> - Add lots of comments in your code to help others or even yourself in case you forget what your thinking was.

Lots of comments is a red flag to me. It often indicates the code itself is of poor readability. But it's usually easier to just slap some comment on it than to properly rewrite it... "A comment is a failure to express yourself in code" (Uncle Bob).

> These are just a few examples of good programming practice

I'd argue they are debatable, and at the very least not necessarily universal.

Ah, the most important rule - there are no rules, only compromises.

About the comments, by no means do I mean that comments can be a crutch and should allow for sloppier coding, but sometimes the problem that you're trying to solve requires a lot of brainstorming, and when you hit your "aha" moment, you'd better write down what your thinking is, in English. The code itself might be pretty hairy to go over and decipher if that's all you've left yourself.

But I get what you mean, and you make a valid point.

Sometimes code simply cannot speak for itself, and then a comment is very welcome, sure.

What I learned though is that a lot of programmers suffer from a form of a "comment blindness". I was once asked to explain a piece of code for which I already provided that exact explanation in the form of a neat, verbose comment, on this every screen : )

In my experience, programmers develop this "comment blindness" kind of like an everyday person numbs themselves to omnipresent ads via so-called "banner blindness".

Basically, most of the comments one encounters are redundant, stale etc. and therefore useless. So the less comments overall, the better the chance for the ones that matter to stand out.

At the end, there's no silver bullet, and while as experienced programmers we find it obvious and needless to say, I guess it probably is a valid takeaway for juniors to take most guidelines as rules of thumb only, and avoid falling into dogmatism (the mother of cargo cult)...

I remember looking at used books in my college bookstore, and found one which had nearly every sentence highlighted in yellow. The book might as well have been dipped in yellow ink! Overuse of the highlighter amounted to not using it at all.

I agree, comment judiciously.

I put a lot of comments in my code, but not to explain what the code does, moreso to explain why it is doing what it is doing, what it used to do and why it changed, and what else I think it could do instead of what it is.

- Subroutines must have one entry point and one exit point, and accomplish one task.

Good thing every programming language nowadays enforce that lesson. I can only imagine how horrible it must've been to reason about a program when a method could just GOTO away and never come back.

> Practice, practice, practice is not necessarily good advice if you don't know what you're doing.

The lacking part is not knowing what you are doing (if you know what you are doing, why do you need to practice?), but having enough introspection to be critical of the code you just wrote.

Practice without learning, and learning without practice are both dead ends. The two go hand in hand.

As someone wise said: Practice makes permanent, not perfect.

Given the book you recommended is out of print, do you have any second-best recommendations?

I code often as a statistician and data scientist, but am at a point I need to learn better craft. I'm all ears!

Are you looking for a book geared toward a particular language, or one aimed more at better general programming methodology, regardless of language?

Either and both. I am a Python user with some C/C++ and Fortran experience. I dabble in other things, but those are my primaries.

Then I would say The Elements Of Programming Style, and possibly this one (I haven't read it, but from the description it seems to be what you're looking for): https://www.amazon.com/Elegant-SciPy-Art-Scientific-Python/d...

Kernighan and Plauger "Elements of Programming Style" may be out of print, but there seem to be many used copies available. For example:

https://www.amazon.com/gp/offer-listing/0070341990/ref=tmm_p...

Philosophy of Software Design by John Ousterhout was a great quick read on designing good code.

It's not practice makes perfect, but perfect practice makes perfect.

Yes, practice makes permanent, including bad habits.