Where to learn coding quality and best-practices



  • Heya,

     I've been a long-time reader, occasional commenter. I'm an electrical engineer by training, but programmer by trade. I went to school for electrical engineering, which involved some programming, but more from a utilitarian standpoint, rather than being the core focus. I worry that because I didn't specifically go to school for programming that I may be lacking in programming quality and skills; and I want to be able to provide high-quality code if at all possible. I work only with a small number of people, and the codebase is all homegrown, so I have very little exposure to a good, well-layed-out application, and/or methods.

     Thus far, I've been able to manage on my own, and try to implement things that I've heard/read about that make sense, everything from best programming practices to overall things, like separation of development and production environments.  There are some big changes in the works here though, and I want to make sure that I'm not left behind. I consider myself relatively smart and able to pick up on things, but again, I work in a vacuum and just don't have exposure to the "right" way of doing things, only my way that happens to work pretty good for me right now. I'd love to find out best practice on things ranging from really high-level concepts (when to use development environment, etc) down to specifics of coding and language (when exceptions are good and bad, when and where to use classes, methods, templates, how to use object-oriented programming in a smart and efficient way, etc). I realize a lot of it is experience in doing it, but some guidelines to start me down the right path would be awesome. 

    So, I know this is very open-ended, but how do you all make yourselves better programmers? What resources do you use? Any languages you could recommend that encourage good habits (I realize any language can be done appropriately or not, but some are more structured from the get-go). I don't want to end up the source of a future WTF. 

    Additionally, what sorts of things do you do for your own personal projects, do you use things like CVS for quick one-offs or while you are just learning? 

     Thanks,

    -J



  • Personally i like books, they just fit so neatly on my shelf. Although occasionally i do read them. Personally i like "the pragmatic programmer", "code complete", "head first" - series.

    For personal projects i don't bother with revision control, but at work the rule of thumb is that "Not commiting your code is the equivalent of deleting it". With the general accepted side note that it shouldn't actually break anything. Also keeping your local copies up-to-date should be a high priority when working. Nothing beats finishing a change and finding out someone did a lot of changes in the code you touched.

    Also, and this might just be me. But to me, code can look ugly. Not even in the sense of hard to read or anything, but in the way when you squint your eyes and look at the code and it isn't visually pleasing. To me that's a sort of gut feeling that the code isn't good. Perhaps a bit of indentation and a few enters and spacing spaces might fix it. Anyhow, i just find that pretty code is nicer to work with. Not pendetic about it or anything, but when i see variable assignments that are related but don't have the asignment aligned, i tend to fix it.



  • Once code is written, only one thing can happen to it, which is maintenance. Be kind to others and your future self by making sure the code is maintainable. That means that if you have a Thing to do, make sure you set things up so that this Thing is easy, rather than an frontal-lobe-gouching experience.

    @stratos said:

    Also, and this might just be me. But to me, code can look ugly, in the way when you squint your eyes and look at the code and it isn't visually pleasing. To me that's a sort of gut feeling that the code isn't good. Perhaps a bit of indentation and a few enters and spacing spaces might fix it. Anyhow, i just find that pretty code is nicer to work with. Not pendetic about it or anything, but when i see variable assignments that are related but don't have the asignment aligned, i tend to fix it.

    I agree, but not on the specific point you mention. I care fuck-all about aligning assignments. :)



  • @stratos said:

    Also, and this might just be me. But to me, code can look ugly. Not even in the sense of hard to read or anything, but in the way when you squint your eyes and look at the code and it isn't visually pleasing. To me that's a sort of gut feeling that the code isn't good. Perhaps a bit of indentation and a few enters and spacing spaces might fix it.
    My favorite feature of Eclipse is the Format Code feature.  Like dhromed, I don't care fuckall about indentation while I'm writing, but a right click-> Fformat Code takes care of me.


  • ♿ (Parody)

     I find interaction with other programmers (about programming!) to be really helpful.  Basically, become a part of an online community where you're interacting, sharing code, etc.  I find that this helps in multiple ways.  Direct interaction talking about subjects of interest (development, management, language features and abuse, etc) are one great way, and you can gets lots of benefit just from lurking.  You also get a lot of exposure to other people's code.   Most of it probably won't follow anything like best practices, and you'll often think that it should be on the front page here.  But learning what not to do is often more important than learning what to do.

     Perhaps the most important thing is to think about things.  Don't follow some advice just because some [allegedly] smart person gave it.  It might really be the best thing for some situation, but if you don't understand it, you're just a cargo cult programmer, and you'll apply it in places where it isn't really appropriate.

     Just because you work in a vacuum doesn't mean that you have to stay in one all the time.



  • Read TDWTF and don't repeat the WTFs. Especially the Side Bar WTFs contain a lot of stuff that isn't *that* ridiculous (like the ones on the front page), but are often very commonly seen in people's work.

    Agree with stratos, ugly-looking code usually is badly written.



  • @belgariontheking said:

    Like dhromed, I don't care fuckall about indentation while I'm writing
     

    Wait, my point was unmade.

    I don't care about aligning assignments.

    That's all.



  • Couple of suggestions:

    Don't be 'terse', either in code or in comments. If you come up with a 'clever' method of doing something, be aware that, when you look at it again in 6 months' time, it may look like gibberish! It may sometimes be better to do the long-winded solution, as it's clearer. Comments should express your intentions, i.e. what you are *trying* to do and why, rather than what you are doing. A comment like "add 3 to date" is less useful than "jump to next Monday". And it's better to have variable/method names that are too long, rather than too short; this *can* get silly, but a method called "add" causes hell if you decide to do a global replace.

    Work out a set of naming conventions, and stick to them. Other people's code will give you ideas, but if it's a bit 'wrong' or strange, that's no big deal, as long as it's consistent. For example, Sybase naming standards aren't great, but at least I know what to expect.

    As a general rule, any half-decent programmer always thinks he's better than the rest, so others will *always* find fault (look at the petty quibbling on this site!). This does not make them right or wrong, just a bit picky.

    Experience of working with others is a great thing, and does tend to develop good practices. As an alternative, see if there is a 'cookbook' for the language you are using - they can show the way to good technique. Good luck!



  • @vr602 said:

    but a method called "add" causes hell if you decide to do a global replace.

    Decent IDEs understand the code and will be able to rename methods/vars without a cold S&R.



  • @dhromed said:

    @vr602 said:

    but a method called "add" causes hell if you decide to do a global replace.

    Decent IDEs understand the code and will be able to rename methods/vars without a cold S&R.

     

    True, but i tend to agree with cr602.

    For instance when you have a class "itemDump"  with the method "add", it's all wel and fine. But when the scope grows and i need to be able to add for instance subgroups, i would get "add" and "addGroup".  In that instance i would rather have "addItem" & "addGroup" so i need to refactor the method "add" to "addItem". If i would have been specific from the beginning it would have saved me time later on.

    Above is of course just a example to show the point, in the end it's moot, because like you say in modern IDE's it would be a few clicks to refactor the method name. From a perspective of preference however i like to be specific from the beginning.



  • @stratos said:

    For personal projects i don't bother with revision control, <snip>

     

     

    Seriously?  I'm sorry to hear that.  If you practice good version control at home, it will naturally extend to your workplace, and then you will avoid any "oops" moments.



  •  Use descriptive variables, indent, and comment on anything that may not be obvious.

     and if you have something like a javadoc, use it. Maybe later when you are looking at descriptions for functions that you wrote you will be thanking yourself because you know exactly what needs to be sent and what it will do.

     

    Also use good file names! I hate looking for something and having to look through files named "roapdoasndjkh_12007_NEW_NEWER_NEWEST_DONTUSEANYMORE"



  • @dhromed said:

    @vr602 said:

    but a method called "add" causes hell if you decide to do a global replace.

    Decent IDEs understand the code and will be able to rename methods/vars without a cold S&R.

     

    Not if you are using Perl or it's dynamic bretheren.



  • Give TPOP a try, it's a short read but densely packed with useful stuff.


Log in to reply