Ask HN:What's on your list of good programming principles?
4 comments
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.
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.
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.
Modularise
Abstract
Code, test, revise, functional test, Load test, Performance test
Peer testing
Comment
Simple is beautiful
Abstract
Code, test, revise, functional test, Load test, Performance test
Peer testing
Comment
Simple is beautiful
Of course, there are things like DRY (Don't Repeat Yourself), etc.
I just wanted to tap into the collective wisdom and experience of HN to see what you guys think are the top programming principles.
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