What should I do to improve my code/style of programming?

Question

I am sure you guys know me. I am the person from your offshore team whose code puts you off and at times makes you pull your hair (bcoz you can't pull mine). My programming concepts are quite okay (and I continuously try and improve them by reading blogs, articles). But, my code isn't up to the mark. It has got better with experience, but still isn't as good as some of colleagues. My code does does what it wants to do, but not in an optimized/graceful manner. How can I improve?

Answer 1

The most important point in my opinion is - Make it readable

• Choose meaningful names for variable, methods and classes
• Extract code from large blocks to focused methods
• Consistent indentation and no long lines
• ... (start with naming it's one of the most difficult areas :) )

Few more tips:

Write units tests, if can be done in TDD manner it's even better (but it can be done mostly when your team does it, it's hard to be alone writing unit tests)

Don't work too hard on many areas at once, e.g., don't work too hard on your design skills while you're working on refactoring skills.

Define goals and get feedbacks, choose area for every week or two and focus on it, for example after having ability to write readable code you can focus in design principles, later on design patterns and after that to optimizations (all examples, maybe there are more relevant areas to your job).

Bring knowledge to the team, from time to time share with things you learnt in blogs for example in a short "lecture". The greatest benefit is the quick feedback you get, it's more important than the knowledge sharing itself.

Good luck!

Answer 2

Code review is one of the best methods to improve code quality. Before each and every check-in grab someone of your team (whose code you appreciate) and have him code-review your work. Ask him to point out any matter he sees.

Other than that, read more blogs and more books - I liked Alexandrescu's code standards. Try to read your own code and critic yourself. Fix whatever you think needs fixing. Ask more peers to review your work. If you are consistent with that, you will improve.

Answer 3

It may sound easy but it is deceiving - try to keep your functions from doing too many things, having ideally a single responsibility. It will make your code easier to test and a lot more professional looking.

Answer 4

Write the code like psuedocode. The main function should start reading like a story. If there are messy parts due to optimization or a badly implemented external library -- well, firewall it behind more of your story written code.

Answer 5

How much exposure have you gotten to other people's code? Consider finding an Open Source project and trying to participate in it. Trying to maintain someone elses code will show you both how their style is helpful, but also how it falls short.

You can also try some programming competitions, like TopCoder. The Algorithm contests give you lots of opportunities to right small programs that can really use some "elegance" to get them right. You also have to read many different people's code as quickly as possible and determine if it is right, again letting you judge the pros and cons of other people's styles.

Answer 6

MS has some great resources. Here are some I shared with our team:

• Naming Guidelines
• Type Usage Guidelines
• Member Design Guidelines
• Error Raising and Handling Guidelines

Answer 7

You are on the right track by reading other's work! That's great and your asking so your desire to improve is a huge factor in your favor!

One of the biggest items I see to improve code is to refactor it (best done with unit testing).

Break up long/large routines/classes into smaller units. Try to have each routine/class only do one thing (single responsibility).

There's a lot of other ideas for example such as learning to apply SOLID principles to your code.

Here's some links that speaks more to this and has some samples:

http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod

http://www.lostechies.com/blogs/chad%5Fmyers/archive/2008/03/07/pablo-s-topic-of-the-month-march-solid-principles.aspx

http://www.davesquared.net/2009/01/introduction-to-solid-principles-of-oo.html

Paraphrased from links...

S - Single responsibility - This means that a class should only do one thing. A class that does this makes it easier to change and conversly one that doesn't is much harder to maintain.

O - Open for extension, closed to modification - This means you should only change a classes behaviour by using inheritance and/or composition. It also means you should be careful in how you design your classes to be resilent to change in such a way that they won't easily break code relying on it.

L - (LSP) Derived objects should be substituable with the parent and everything should work properly. - This means that when you use a subclass in place of its parent everything should work. This may seem simple but take the classic square derived from a rectangle class and what happens if you have a parent method to set the width. This is different for a rectangle and a square.

I - (Interface segratation) Interfaces should only be forced upon those who use/need them. - Keep your interfaces small and to the point to help ensure this rule. Don't create large interfaces much like creating large classes as they start to break the Single responsibility rule.

D - (Dependency Inversion Principle) Break Dependencies. - Use interfaces instead of types when possible to help break dependencies between classes.

Happy coding!

Answer 8

Go back to some old code you wrote that you would have forgotten and try to understand it. Improve your old code while you go. A lot of times I find little blocks of code where I had no idea what was going on. Figure out what's going on and comment on it.

I do this on a regular basis, and eventually in the back of my head I get a little voice telling me that the future me won't know what I did here, and I'll make sure it's clear while I write.

Answer 9

There are some very good books on how to write better code, for example Clean Code by Robert C. Martin, which I strongly recommend. "Refactoring" is one key technique: the application of many small improvements that each preserve semantic correctness but improve the code in some way (flexibility, comprehensibility, etc.) Martin Fowler's 1999 Refactoring, and the new 2009 Refactoring in Ruby are good resources for this.

Answer 10

Learn another programming language, preferably something very different to the one you are currently coding in. I was surprised at how much my Java improved after I learnt Lisp. Knowing lots of languages allows you to think in terms of more general abstractions, rather than in terms of the language you know best.

Eric Raymond talks along these lines in How to become a hacker

Answer 11

If your colleagues write better code than you, then consider asking them to review your code!

The single most efficient way to get better is to get a good mentor. Your boss might be interested in helping you here.

Answer 12

There are plenty of things you can do. the most important of them you've already done - Caring about your code quality. once you care, you are on the right path. for further improvement, try do the following:

1. Read other people code and try to learn from it.
2. Get involved in some open source projects. you don't have to be active. just reading and understanding the code will improve your coding skills.
3. Ask one of the senior programmers in your team to review your code and learn from their inputs.
4. read books. Clean Code has a lot of simple wisdom inside. highly recommended.

Answer 13

Read code complete by McConnell which is in its 2nd Edition that helped me.

Also learning how to get the best out of the debugger, using tracing techniques and performance counters is vital particularly if you are writing a complex algorithm.

A great insight into a master at work http://norvig.com/sudoku.html

Read other peoples code - it is far far easier writing code than reading code. Work with people that are smarter than you.

Much of this has been said before but I believe you can never get too much advice.

Its a long journey that I am still travelling for sure..

Answer 14

Put comments in your code of what you "expected" your code to do. That way when i (or your favorite colleague) goes back into your code to debug, we'll know what we expect the code to do, so we should be able to follow your logic and collaborate for better ways to solve the problem.

Answer 15

I found it was a combinational thing.

I found that reading the Head first Designs patterns book gave me a better understanding of how to use patterns which simplifies the code.

Proper naming of variables makes the maintaining of the code easier to use.

Commenting all classes and function with the input out puts and intended purpose also aided in maintenance.

I think that possible the biggest thing was having a coding standard to work to which forced my coding to a similar style to the rest of the team which has helped when maintaining the code.

Thinking about maintenance before coding and carrying out suitable class design and documentation which lead to clearer objectives for classes and functions.

Peer code reviewing helped a lot, but only if the points raised are taken in the right way.

Practice and keep looking over the code you've written helps.

Answer 16

One of the funnest things I have done to increase my coding ability was to get to level 1 of projectEuler.net. It was challenging, fun and educational. You can also do it in any language you want. When I was learning Python I would do them in Python. Now that I am learning C++ I would probably still do them in Python :(

The second best thing that has helped me (because I lack discipline) is taking classes. Local JC's (if you live in the US, west coast is best for this due to costs) usually offer cheap online classes that can still be quite good. I am currently taking a data structures class at PCC.edu - it is not easy.

Answer 17

I am an english major and everything I have learned about coding styles has been from looking at other people's code. My advice is to find what works for you. Recognize what works and what doesn't work in other people's code.

Some of the first code I looked at was from a programmer who used hungarian (?) notation. Everything was strThis and objThat even tables were tblWhatever. At the time that worked, but now I prefer to drop the prefixes for anything other than page objects like btnSubmit, or lblMessage which helps me remember what I am looking for. I can name other variables english words in camel case that just seem (to me) to read better in code.

As far as the tbl prefix goes, that seems unnecessary now. But other prefixes might make sense, like my initials followed by an underscore for tables that are my customizations.

So, learn from other peoples code, but ultimately do what makes sense to you.

Answer 18

There are several ways of improving yourself and there are so many books on that topic. So I'll list whatever I think is the way to improve.

The first step to improving your programming skills requires you to do everything wrong and that will lead to the heading of the initial and most important step…

Step 1. Reach Your Pain Point!

This may seem a bit zen, the only way you'll learn how to do programming right, is to eat your own dogfood. This is a very hard lesson to learn for many programmers, and this is really what keeps most programmers from writing maintainable code. These kinds of programmers are not feeling the pain themselves, and shy away or block off the pain that is their code.

I say: Don't do that! Instead make a mistake that will hurt you so much that you absolutely can't stand and you'll literally start weeping in tears… and most importantly learn from it.

This I learnt the hard way… several times. There is nothing wrong with making mistakes, but there is a great deal of wrong of not learning from them. I want to emphasis on "learning" here, i.e. to really go through everything that went wrong, or was problematic, and find a solution to how to do it differently but better. Here is an anecdote of mine:

Once I tried to make a database application on Java (which was a school assignment), using only one frame class with lots of tabs. All the code resided in the same code file. It was hell programming it all because of several reasons:

• Each time the compiler had to build one giant code file took almost half a minute. Also scrolling through one giant code file is a pain in the butt.
• Unclear requirements from the assignment left for a lot of interpretation. And most of them were wrong.

I failed the assignment and had to do it all over again, which made me really angry, and this was only partly because of the code which pained me so much to see.

…but I had time now and I was determined to show that asshat of a teacher that I will code the best damn database application EVER. So for the points above I did the following:

• I started over from scratch, this time breaking up the logic in several classes. This cut down compiling time drastically. It only took a second or so to compile, as classes that weren't touched didn't need to rebuild. It was also easier to find what I wanted because it's easier to open up a small file than to scan through one giant one.
• I wrote a requirements report, 40 pages long, one all the design considerations (both UI and database) and why I decided for one over another.

I managed to do it, in time, and over the teacher's expectations. Little did I know that several years later when I got into the software making industry that I'd be maintaining a database application that had the exact rookie mistakes that my early database application had.

Oh, how I hate going through the pain of maintaining a >5000 LOC source file one more time. This time it was a .NET app instead of a Java one.

So how can you reach your pain point?

I've found the most effective way to reach your pain point is to write a program for yourself, one that will make your life easier. Then leave it for a while and resume after several weeks or so. I dare you, you will hate your own code…

…but this is normal. Now find out why you hate it. What's the thing in your code that's so painful to see that it is bugging your mind? What are the steps you can take to avoid this mistake in the future?

---

If there is one step you need to take, it is the one above. All other steps from here on out are the tips that everyone will give you to make your code better.

However there is no point of going through them unless you're ready to improve because you really, whole heartedly, can't stand your own damned code. Because then, they will all stick.

Step 2. Go faster!

There are a lot of things that your editor or your integrated development environment (IDE) will do in order to make you go faster. Find out all the short-cuts, code-assist features. Start doing things quickly. Don't stop at the small details, look at the big picture.

Retyping code a lot to the point of being too repetetive? Use "search and replace".

Trust me, going for speed lets you gain experience points that you can spend on learning more programming stuff.

Step 3. Refactoring time!

Yes, start to learn refactoring. In order to refactor, you need to find a code smell. Something that catches your eyes that just looks wrong, so wrong that you are wanting to correct the wrongness… Actually, it shouldn't smell for you. Instead it should give an stinking odeur instead for you. You need to be as sensetive as a high class chef. That way, you will refactor, and you will make it smell nice again.

Refactoring can be complex, refactoring can be simple. Try to do the simple ones first as you should know them already. Such as extracting code to it's own method.

If there is one mantra you should follow when refactoring it is "Strike three! Refactor!". I.e. if whenever you find yourself copying the same piece of code third time you should stop right there. There are ways to avoid code duplication. Move it into it's own method, or even a class.

There are a lot of ways to refactor, so go through a catalog and have a taste on which ones that will suit you the best. Some may give you new ideas on how to clean up your code. Also be using a refactoring tool in your IDE to do the job for you.

Step 4. Become inspired!

If there are two books that you just have to read, then there are two: Code Complete and Pragmatic Programmer. The latter book is a more hip and lighter version of the former.

Also go through the list of answers in this page, there are a lot of good tips.

Read them all and engage yourself! Why? Because these tips will help you alleviate your pain points. Thus, the only way you'll get something out of the tips, is if you had pain points to begin with.

Answer 19

The biggest thing you can do to improve your code:

COMMENT YOUR CODE

Ok, don't over do it thought, like:

System.out.println("hello world"); //Prints out hello world
int x = 0; //Set x = 0

I'm sure we all know what that does...and that's redundant, but add meaningful comments to your code, trust me it helps.

Answer 20

• Plan your code out before you put a line down.
• When/If something is not clear; Ask!
• When/If you're unfamiliar with the domain, spend time chasing the domain; discuss it with # your colleagues on-shore, and off-shore.
• Adhere to any coding conventions

The difference will show in your code, and may even reduce rework

Answer 21

Read the following books

• Code Complete 2
• Refactoring: Improving the Design of Existing Code

Answer 22

At each point in your code, ask, "What do I know to be true here?" Then, code explicit checks then and there, for two reasons:

1. you can't handle what you're not expecting.
2. you can't remember now what you knew to be true here last year.