hcuqwq
Last Updated: February 25, 2016
·
10.93K
· vinitcool76
0474e465f54e54cc1225d67dfd5d9be5

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.

Say Thanks
Respond

17 Responses
Add your response

8016
D0c48936ccbd3f2b0144e5e472005921

Really good.

About the detailed commit message, could you show an example?

over 1 year ago ·
8017
0474e465f54e54cc1225d67dfd5d9be5

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 ·
8042
I 5975f6 1314372

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

over 1 year ago ·
8043
0474e465f54e54cc1225d67dfd5d9be5

Exactly.

over 1 year ago ·
8061

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

Add environment specific config settings.

over 1 year ago ·
8082
D0c48936ccbd3f2b0144e5e472005921

@vinceve, thanks for the reply.
That's how I already work, I though it was something more detailed.

Thanks ;)

over 1 year ago ·
8085
32b6de7d5abfe436f9b7e86c50f73eae

Absolutely.

over 1 year ago ·
8093
D42a7264714dee5006b9c99d2567a320

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 ·
8094
0474e465f54e54cc1225d67dfd5d9be5

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 ·
8099
9b029fbe569b3af35c235aedb2420b7b

Good article man, thanks for remind me this.

over 1 year ago ·
8109
Sasquatchsketch

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

over 1 year ago ·
8177
37e4b1979ea9f93181ba05e04216749d

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 ·
8197
Mextures

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 ·
8199
0474e465f54e54cc1225d67dfd5d9be5

@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 ·
8272
7d1040ca61fcfe6e3311776feb62773a

@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 ·
8333
E508619a35122f55616b9332f00b9e47

@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 ·
8339
0474e465f54e54cc1225d67dfd5d9be5

@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 ·