4 ms·
1.) Comment! Not only does it make the code easier to interpret, but it can also bring logic errors to light as you think through why you implemented something
by fhood 10y ago
1.) Comment! Not only does it make the code easier to interpret, but it can also bring logic errors to light as you think through why you implemented something in a specific fashion.
2.) If the language supports error handling (try catch/except) learn it and use it.
3.) Use descriptive variable and function names. Even if it means more typing, the readability is worth the effort.
4.) Use proper code style. Most languages have conventions for style that include what should be capitalized, whether to use camel case or underscores etc.. Learn them and use them.
5.) Write a lot of code. I don't think that there is any real substitute for experience.
- CuriouslyC 10y agoIn re: comments, I've found that any time I would write a comment, I try and see if I could re-write the code to make the comment redundant. It is possible to do this in a surprisingly large number of cases. As for #5, practice makes permanent. Writing lots of poorly thought out code just ingrains bad habits.
- fhood 10y agoSure self explanatory code is the goal. But in the real world this is never entirely possible. File parsing for example. Without seeing the file being parsed it can be very hard to interpret the code parsing it. Or maybe you are interacting with other software that doesn't always respond predictably to your code and you need to explain why these calls are made in this order. I agree that practicing bad habits is unhelpful, but I still maintain that the best way to get better at programming is to program, particularly by writing and contributing to open source projects in your spare time.
- davidsawyer 10y agoI'd caution not to use commenting as a crutch, though. Code really ought to be readable and easy to follow all on its own. I don't think code should be littered with comments just narrating what's going on, since those can get out of sync easily when code is modified. The code itself ought to be descriptive enough to "tell its own story", so to speak. Comments ought to explain why something is happening if the author feels the code may be unclear.
- brianwawok 10y agoAgreed. If I find myself typing a detailed comment past TODO FIX THIS TOMORROW, I refactor. It is rare code should need a comment. Pulling a clever trick to trick the JIT into inlining a function call? Cool add a comment. Just loading junk form a database to show a user? Should not use a comment.