TE
TechEcho
Home24h TopNewestBestAskShowJobs
GitHubTwitter
Home

TechEcho

A tech news platform built with Next.js, providing global tech news and discussions.

GitHubTwitter

Home

HomeNewestBestAskShowJobs

Resources

HackerNews APIOriginal HackerNewsNext.js

© 2025 TechEcho. All rights reserved.

Ask HN:What's on your list of good programming principles?

8 pointsby sendosalmost 14 years ago
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

4 comments

bartonfinkalmost 14 years ago
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.<p>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.<p>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.<p>tl; dr - log everything you can because it may very well save your ass down the road.
mmccombalmost 14 years ago
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.
mcphilipalmost 14 years ago
No magic numbers<p><a href="http://stackoverflow.com/questions/47882/what-is-a-magic-number-and-why-is-it-bad" rel="nofollow">http://stackoverflow.com/questions/47882/what-is-a-magic-num...</a>
sidcoolalmost 14 years ago
Modularise<p>Abstract<p>Code, test, revise, functional test, Load test, Performance test<p>Peer testing<p>Comment<p>Simple is beautiful