Last Updated: January 22, 2020
·
12.09K
· vinitcool76

Seven Tips To Get Better At Writing Code

Every developer dreams of getting better at writing code. He/She wants the code to be clean and pragmatic. But it doesn't happens on its own. Here are some tips to get better at writing code:

  • Follow TDD: Test driven development is a great way to improve code. It ensures that the functionality you implement is doing what it is should. You make sure to spend some time writing tests before writing a feature. It is a difficult practise to inculcate in your team, but trust me the amount of time and stress you will save because of it is phenomenal. Basically, there are two types of tests that should be present with your code:

Unit tests and Integrations tests. Both are equally important. Sometimes, it might not be possible to get everything unit tested but make sure key parts have units tests and integrations tests are complete.

  • Write good and detailed commit messages: I can't recommend this one enough. Ever since I got introduced to this practice, I could easily feel the improvement in my code. I prefer it to writing long comments in my code. Wherever you did something that needs to be explained or if you did a hack to resolve some particular issue, make sure you address these parts in your commit message. It really helps because whenever your code base gets bigger.A new developer could just take a look at the code and commit message. He will be more comfortable getting up to speed. Also, if you are working on an Open Source project and follow this practice, chances are really high that your pull request will be merged. One reason for this is that, the person merging your code will not have to dive deep into your code to make sense of that you did back there. Your 'detailed commit message' will serve its purpose then. Though your commit messages shouldn't turn into project documentation: while you should put a summary and a short list of things you changed in a commit, long explanations of algorithms, data structure and overall project architecture should remain and be maintained in project wiki (or whatever tool you use for internal documentation).

  • Teach yourself about writing maintainable code: Always, try to think about writing maintainable code. It might not be possible every time because of deadlines. But make a point to revisit that code and fix that hackery you did back there. This is really important, because sooner to later, that hackery/bug will come to bite you and things could get really ugly.

  • Know your editor: You should and must configure your editor for the language your code. It must have all the required plugins to do live linting. If you do python or JS, there are some pretty great plugins available for both the languages in Vim and Sublime Text2. Also, get familiar with some good snippets generating plugins for frameworks, HTML and CSS. There are pretty great plugins to beautify and minify your code as well. They really help in getting the whole code quality better.

  • Automate all repetitive tasks: At this time, we are pretty much equipped with the technologies such as grunt and yeoman which could automate a lot of part that you had to waste your time doing again and again. You must also learn about git hooks. For example: I made a git pre-commit hook to compile less into css and run jshint, concat and uglify operations on my JavaScript code any time there is some change. This is awesome because my workflow prevents any bad code to enter the code base.

  • Read good code, data structures and Algorithms: There is no end to learning. Teach yourself to read more and more good code. You must spend time getting better with data structures and algorithms. They might not prove useful immediately, but it will make you a better developer and will enable you to take better decisions in future.

  • Watch talks and presentations: Be regular to watch great talks and presentations from the various conferences round the year. They give some pretty great information about the latest trends and techniques. You could easily find them on YouTube/Vimeo and SpeakerDeck.

Picture

For more interesting blog posts, visit http://www.gotchacode.com

Edit: Thanks dpashkevich for your great remarks on commit messages. Added them to the commit messages section.

15 Responses
Add your response

This comes from one of my Pull Requests, I am sure it will help you understand. https://docs.google.com/file/d/0B-gH8xrN3O5fTHVFU3hVellBckk/edit?usp=sharing

over 1 year ago ·

+1 for automation. If a computer can do it, why should you.

over 1 year ago ·

Exactly.

over 1 year ago ·

@gerep try starting your commit message with the action you have done. For example:

Add environment specific config settings.

over 1 year ago ·

Absolutely.

over 1 year ago ·

Great writing, thanks for sharing!

I'd also notice, though, that your commit messages shouldn't turn into project documentation: while you should put a summary and a short list of things you changed in a commit, long explantions of algorithms, data structure and overall project architecture should remain and be maintained in project wiki (or whatever tool you use for internal documentation).

over 1 year ago ·

Yeah, you are right. Those things are for documentation/wiki only. But sometimes it is good to explain some part of tricky code just as a reminder for you for future reference.

over 1 year ago ·

Good article man, thanks for remind me this.

over 1 year ago ·

Great article. Always surprises me when someone writes code that even they can't maintain 2 months later.

over 1 year ago ·

Agree wholeheartedly, especially with the automation and de-linting.... Suggest a regular review of good design patterns as well as data structures.

over 1 year ago ·

As a relatively new developer, I have found this post to be outstandingly helpful. I have been struggling a bit with data structures and algorithms but, I will not give up trying to master my understanding of them

over 1 year ago ·

@mixedmedia: Great, that is the intention of this post. The post is my accumulated understanding about development and programming. I am glad it could help you. :)

over 1 year ago ·

@gerep I think it's about:

  1. avoiding short commit messages like "fixed that bug". If you have to jump back to a specific commit, it's way faster to scan meaningfull commit messages to find what you're searching for.

  2. avoiding big commits with lots of changes with commit messages like "fixed this bug, fixed that bug....and some more". You and, more important your team/co-workers, will not know what all the "and some more" stuff is or was.

If something goes wrong and you have to find the "rotten apple" it's easier to find it in small commits with meaningful commit messages.

over 1 year ago ·

@vinitcool76 while I appreciate all of your points as being excellent advice. I don't think all of them "make you better at writing GOOD code" mostly just 1, 3 and 6.

I maintain the single fastest and most reliable way to become a better programmer is to attempt to fix bugs and contribute to a MATURE open source library where your code is scrutinized by many seasoned developers and compared against a stable codebase presumably already using good design patterns etc...

Depending on the community around the project, the feedback from the senior contributors will make you a better programmer out of sheer necessity.

That said, design pattern and core language books should be within arms reach at all times. (and SO)

over 1 year ago ·

@petermelias: About the other points, though were not directly related to code quality but were related to code maintainability.
Code maintainability is also very important and it affects the quality of code. Nevertheless, I totally agree with the idea of contributing to an open source project.

over 1 year ago ·