
Ask HN:What's on your list of good programming principles? - sendos
I'm trying to set up a list of good programming principles to give to new employees.<p>Of course, there are things like DRY (Don't Repeat Yourself), etc.<p>I just wanted to tap into the collective wisdom and experience of HN to see what you guys think are the top programming principles.<p>Note that this is intended for non-CS majors, i.e. engineers who code as part of their work, so even if some things are obvious to CS majors, still list them here if you think they are helpful
======
bartonfink
Logs are lifesavers. If you have to figure out what the hell your code is
actually doing, you're much better off if you know there's a detailed log in
place to search. Theoretically you can get the same information by attaching a
debugger, but logs are so much easier to use that it's really no contest.

It's much better to log too much information than too little. Filtering a
crowded log file for a specific piece of information is a very tractable
problem, whereas finding that same information in an empty log file is
obviously impossible. You're even better off with a proper logging library
that has different levels, because that can do a lot of the filtering for you.

All too often in my career, I've had to track down a bug only to find that the
piece of information I need just isn't in the logs or is otherwise swallowed
up (for instance, if an exception is wrapped improperly in another). This is a
pain in the ass, because it usually means that I have to not only debug a
problem but now I have to guess how to recreate it as well. If there were a
greppable string in a log file, I'd at least have some idea where the code got
to before the problem surfaced, but without that clue, I'm just going on app
behavior. Seriously, log everything you can, because you never know what piece
of information will save someone hours of debugging later.

tl; dr - log everything you can because it may very well save your ass down
the road.

------
mmccomb
Code Formatting - when working in a team on a shared code base it'll aid
productivity greatly if you establish a set of formatting standards and stick
by them. Ideally you can translate this to an IDE template and automate
formatting.

------
mcphilip
No magic numbers

[http://stackoverflow.com/questions/47882/what-is-a-magic-
num...](http://stackoverflow.com/questions/47882/what-is-a-magic-number-and-
why-is-it-bad)

------
sidcool
Modularise

Abstract

Code, test, revise, functional test, Load test, Performance test

Peer testing

Comment

Simple is beautiful

