Why is people’s code so bad? Even after getting a degree in CompSci?
I’m fixing code written by some quite junior programmers. I’m always amazed at the code people write. Only in these moments I really see what good code is about. When you read or write good code, it just seems the obvious thing to do, and no big deal.
Principle #1: if one small piece of code is repeated, and it would be wrong if you changed it in one place but not the other, then THE CODE IS BAD! You have to REWRITE it. Just so that you can’t change things in one place and not in the other(s)! It’s that simple.
The simplest case, and one I STILL see too often is numeric constants. You are adjusting some things (say, things in a UI layout done programmatically). You change it in one place, run the program, and it doesn’t work. Or you do something non-direct (like rotating the screen and then going back to the original place), and things break up. You check it, and the position is set in two places, to a numeric constant, and you had only changed it in one place!
The solution is obvious: have a #define at the top giving the right name to the value, and use the constant name in both places. In Java, you can just use some “private final static int” or so. Whatever your languages buys you, but there’s certainly a way (or switch languages, pronto!).
I had this idea that if someone indents code wrong, you should stop looking at it, because the rest will be wrong too. If a developer can’t get indentation right, it’s impossible they’ll get conceptual consistency right. I’m expanding on this idea now: if someone repeats small non-independent pieces of code or numeric constants, instead of refactoring to some simple function or definition, then I won’t bother with it (unless totally unavoidable).
May you never break the DRY principle: Dont Repeat Yourself. I have a theory that every good development practice boils down to just a circumstancial version of this principle. There is one practice that doesn’t fit the bill, so that’s why I’m withholding from sharing until I can really prove the elegance. I can boil all down to “WRITE HONEST CODE”, but that just isn’t so catchy.
The opposite of DRY is the Twins problem: they may look identical but they are not the same person and you can’t refactor them into one. It always takes a bit of judgement to decide which of the situations you are in.
Jare, you’re right, but I see the problem of not obeying DRY much more often! It seems there are too many copy&paste-trigger-happy people out there.
DRY, without a good reason.
I see the Twins Jare mentions, as well as the yak shaving, especially on throwaway programs. People can also easily over-engineer stuff to avoid boilerplating two or three instances of something similar happening in a program.
I’d rather see a repeat of something that’s downright idiomatic than a custom solution to a problem everyone just boilerplates all the time.
Additionally, putting numeric constants at the top is not always as useful as further down in the code next to where they’re used. It can make some errors harder to spot in certain layout situations. Don’t even get me started on putting numeric constants in h files far from the use for no reason other than someone read a software engineering book in the 90s and never read one in the intervening 12+ yeares. That’s just horrible to deal with when it involves layout code or something else where the constant values really do matter.
All that said, copypasta is *painful*, to quote Sean Kelly: Code is read more than it is written
thank you
giuseppe zanotti reviews http://www.vestinsect.me/