what are best coding practices you follow for your work? [closed]

Question

Everybody has their own coding skills and practices. I would like to know what practices other people follow. Please describe yours.

Answer 1

The first three that come to mind are:

• Emphasis on descriptive naming conventions for self documenting code verses extensive comments.
• Frequent code reviews and pair programming sessions.
• White space is your friend!

Answer 2

The Extreme Programming coding practices. Mostly

• Simplicity is the key
• Refactor mercilessly
• Never add functionality early

Answer 3

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.

Answer 4

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

Answer 5

There's only one thing I always do. When I'm done with a task, I commit it to version control. git-gui allows you to read all of the changes made to each file as you compose your commit meessage.

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.

Answer 6

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!

Answer 7

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.

Answer 8

The Boy Scout approach: always leave the file/function/class you worked on in a better state when you leave.

This encompasses everything:

• code: small refactoring, extract subfunctions, etc...
• comments
• cosmetic: indentation, naming convention, spelling

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.

Answer 9

• CamelCase
• meaningful names
• XP/TDD/BDD

Answer 10

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).

Answer 11

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.

Answer 12

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.

Answer 13

The single best coding practice I following in my work is:

• Ensure the Business Rule that each bit of code is doing is explicitly apparent. If not in self-documenting in the code, there must be a comment. It will save some future poor soul many hours.

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

Answer 14

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.

Answer 15

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.

Answer 16

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.