Everybody has their own coding skills and practices. I would like to know what practices other people follow. Please describe yours.
Tell me more
×
Programmers Stack Exchange is a question and answer site for
professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.
|
closed as not constructive by ChrisF♦ Jan 10 '12 at 15:47
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or specific expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, see the FAQ for guidance.
|
The first three that come to mind are:
|
|||||||||||||||||||||
|
|
|||||||||
|
|
The Extreme Programming coding practices. Mostly |
|||||
|
|
I follow what exists in whatever I'm working on. If something new, my style is pretty much the same as the Linux kernel, provided that the people I'm working with support that decision. In other words, I'm quite comfortable following whatever exists. Whatever annoyance that may bring, failing to pay bills is worse (they war dial you). |
||||
|
|
|
Single Responsibility Principle Meaningful names Avoid unnecessary comments Write unit tests - pay special attention to boundary conditions Using interfaces if appropriate Avoid meaningless try...catch Avoid unnecessary 'if' statements ... List goes on! I will stop for now! |
||||
|
|
|
1: Always make proper comment to your code 2: Take backup before making larger change 3: Make proper document even if it's minor change 4: Don't concentrate much on making less number of line in code.. end user can never see that. What he/she will see the speed of the execution of code which is more important for them. |
||||
|
There's only one thing I always do. When I'm done with a task, I commit it to version control. As an almost religious practice, I work my way through every change I made to every file in the commit. I explain what changed and why. Most of the time every change can be summarized pretty clearly ("Fixed bug #12345"), and I don't clutter up the commit message with pointless wordy prose. Sometimes the changes are a bit more involved, and represent conscious decisions to change how a feature works. On occasion, I can't really remember why I made a change, or at least not well enough to explain it in words. On those occasions, I don't commit that code. Those changes get stashed or reverted. If I don't understand code I just wrote well enough for this, that's a bad sign, and I don't feel guilty about discarding the time I spent on it. One advantage of this that may not be so obvious is that it keeps me committing changes frequently. Sometimes I'll look at a bit of cleverness and have to think about it for a while before I know what it does (Wrote it the previous evening, and forgot how it works by the next day). Although I can write the summary well for what it does, but This is a good opportunity to go back and add some comments to the source that explains the how and why it does it. |
|||||
|
|
The single best coding practice I following in my work is:
After working on a corporate code base that stretches back over 15 years, it is burned in my subconscious. I will not do to others what has been done to me |
||||
|
|
|
KISS - Keep It Simple (and) Stupid! This is a general rule, that applies not only to software development but to many other fields as well. |
||||
|
|
|
Before starting coding a feature/function/component, I setup a test environment so that I can run and observe what I code. This is essentially TDD. May I mention version control as well: it should be as implicit as breathing for a developer. |
||||
|
|
|
My mantra is Write the least amount of clearly understandable code without redundancies nor dependencies that you can get away with You want code that is easy to read and understand, that's nr 1. You also want to avoid duplication of code since it makes the code harder to maintain and just makes things more complicated. You want want as few dependencies as possible, that often goes in hand with the program being easier to understand since each part can be understood on it own but it also makes the code more flexible and reusable Another useful thing I keep asking myself If I were to rewrite this solution from scratch, what would I change? Then I change it, refactor continously and mercilessly |
|||||
|
|
Realizing that it is not the compiler that is wrong it is me. Also that when doing web application development do all prototyping on the command line as it narrows down the number of logical issues with your code. |
||||
|
|
|
The best thing you can strive for is to be able to look at the code you wrote a year ago and identify how you could have done it better. Whether it be through new tools, or new techniques you've learned; you should grow in your skills year over year (and apply that growth to the code you write). To sum up what a lot of people have said in different ways: "Make it work, then make it elegant." If it doesn't work, it doesn't matter how elegant your code is. You can't demo elegant code to users, only working code. But if you just make it work, your code will become unmaintainable, so don't forget to make it elegant after you make it work. |
||||
|
|
|
A few best practices which I follow which cross languages/platforms: DRY - don't repeat yourself. Put anything that looks reusable into its own function/module Modularize - keep individual methods small. If I see a function growing I try to divide it even if the individual functions will be used in one place only. Never treat code as throw-away even if you know it will be. Because: (a) it usually ends up not being throw-away and (b) it builds good habits regardless. |
||||
|
|
|
The Boy Scout approach: always leave the file/function/class you worked on in a better state when you leave. This encompasses everything:
The thought behind is that the next person to come by should have an easier time to figure out what's going on... and chances are it'll be you, so help yourself. |
||||
|
|
|
A general rule is to follow the practices of the environment your are working in, even if those are not your preferable ones. You can find a guideline or better have a look at the code base and learn from what you see. That means if you are extending a framework or writing a module for it, follow the conventions of this framework, e.g if writing for Eclipse, follow the style of Eclipse. If you are writing a C program for Linux, take a look of GNU Coreutils and again follow the conventions you see. |
||||
|
|
