In order to write higher quality code, to better understand approaches taken to solving problems, conventions used and many other aspects of programming (which I couldn’t list of top of my head as of first writing this), there is a lot of information about practices and techniques used to know, understand and utilise in order to become a great programmer. As currently my programming experience is quite limited, I have decided to collate tips, advice and various other useful pieces of information in one place, to be used as a reference when coding.

Remark: Some of items in this post will be very basic, some may become irrelevant over time or not even apply to certain programming paradigms (i.e., there’s going to be a lack of tips which would be relevant to someone writing a functional program). As time goes on I will add and modify the content to ensure its accuracy and get rid of typos. Lastly, this is meant to be a personal reference sheet and in its current state of completeness and quality I wouldn’t recommend anyone to use it. Refer to the sources provided in the references section below.

Table of contents

  1. Basics

    1.1. Naming

    1.2. Commenting

    1.3. Code duplication

    1.4. Minimise class surface

    1.5. Complexity

  2. Design Patterns

  3. Principles

    3.1. SOLID

    3.2. YAGNI

    3.3. DRY

    3.4. Composition vs Inheritance

  4. Other

    4.1. Code daily

    4.2. Read high quality code

    4.3. Useful reads

  5. References

Basics

Naming

Consistency

Regardless of chosen naming/spacing convention, applying the conventions consistently matters. For example if the given naming convention specifies using only upper case letters for constants within the application, then stick to it as personalising the code opposed to keeping entire codebase in the same format, causes readbility, consistency and various other minor issues.

White space increases readability and should be used to separate ideas just like paragraphs in prose.(reddit, 2017)

One letter variables in loops

E.g. for loop, the outer loop should be i, inner loop should be j, then k, etc. This is easier to follow for most people (reddit, 2017).

for(int i = 0;...){
  for(int j = 0;...){
    for(int k = 0;...){
      ...
    }
  }
}

Choosing names

Useful when choosing names(reddit, 2017):

  • Variables are nouns: ( hourly_rate )
  • Functions that do something are verbs: ( compute_sum() )
  • Functions returning a boolean are questions: ( is_max() )

Commenting

Use comments sparingly, usually to reference external documentation or other resources. Filling your code with obvious comments liked int balance; // balance of account isn’t useful and just creates noise. Additionally if you feel the need to excessively comment your code it’s a good sign you aren’t being clear, try adding more methods and making your code simpler to understand.(reddit, 2017)

To be expanded upon…

Code Duplication

Don’t repeat yourself. This includes not analyzing your code for areas where you could generalize a bit. This is a fine line though because there is such a thing as too general or too abstract. Instead of using variable names such as num1, num2, num3, …, numN use more appropriate data structure(e.g., array, dictionary, list)(reddit, 2017)

Minimise class surface

Not everything needs to be public. If it shouldn’t be called by any other code, it should be private. The fewer public members that are exposed the easier it is for someone else to understand what your class does and how to use it.(reddit, 2017)

Complexity

If a function performs more than its’ name implies, then it’s quite likely that the function is too complex. If such is the case, then it’s recommended to break down the functionality into several smaller and more focussed functions. This approach produces much more modular, testable and extensible code, and also reduces places where the function may fail - which helps tremendously when debugging and writing code which needs to be secure!

This same complexity break down approach also applies to classes, and any other aspect of software.

Design patterns

Principles

SOLID

SOLID is a mnemonic acronym for five design principles intended to make software designs more understandable, flexible and maintainable. Acronym introduced by Michael Feathers.

Initial Concept Desciption
S Single responsibility principle “The single responsibility principle is a computer programming principle that states that every module or class should have responsibility over a single part of the functionality provided by the software, and that responsibility should be entirely encapsulated by the class.”
O Open/closed principle “software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification.”
L Liskov substitution principle “objects in a program should be replaceable with instances of their subtypes without altering the correctness, tasks performed, etc., of that program.”
I Interface segregation principle “The interface-segregation principle states that no client should be forced to depend on methods it does not use. ISP splits interfaces that are very large into smaller and more specific ones that clients will only have to know about the methods that are of interest to them. Such shrunken interfaces are also called role interfaces. ISP is intended to keep a system decoupled and thus easier to refactor, change, and redeploy.”
D Dependency inversion principle one should “depend upon abstractions, [not] concretions.”

YAGNI

“You aren’t gonna need it” (YAGNI) is a principle of extreme programming (XP) that states a programmer should not add functionality until deemed necessary. XP co-founder Ron Jeffries has written:

“Always implement things when you actually need them, never when you just forsee that you need them.”

DRY

“Don’t repeat yourself” (DRY) is a principle aimed at reducing repetition of all kinds.

When the DRY principle is applied successfully, a modification of any single element of a system does not require a change in other logically unrelated elements. Additionally, elements that are logically related all change predictably and uniformly, and are thus kept in sync.

Composition vs Inheritance

Most classroom courses love them some inheritance, but in the real world composition via interfaces is much easier to test and maintain. Composition forces you to make your code more modular which makes it easier to test. It also gives you the flexibility of mocking out interfaces until you are ready for them, which lets you focus on the task at hand during development instead of “hopping around” to various functionality when trying to complete a task. This added focus tends to make you write better code in earlier iterations since you are not trying to juggle too much scope in your head at once.(reddit, 2017)

Self note: Yeah, that’s correct, stick to this rule as much as possible! (additional elaboration can be found here)

Other

Code daily

By everyday, I mean everyday! How do professional athletes improve their skills? By practicing on a daily basis. Sure there can be off-days, where you take a break from it, but this should not be the norm. Name one athlete that won a gold medal by only practicing once or twice a week. Learning how to code is very similar to learning a new language or art. It takes a lot of practice! You can know everything there is to know about computers. But without practice, you won’t be able to write code that is maintainable, let alone write something that people would actually want to read.(The Coding Delight, 2017)

Read high quality code

Every developer should read high quality open source code. When I first went through underscore.js and jQuery (not the entire code base), my mind was blown. Let me warn you: because the code is written by professionals, readers need to have a strong foundation in programming and in the language that the source is written in. In the the case of underscore and jQuery, the language would be JavaScript.

In order to get a good open-source education, I recommend finding source code that is

  • Relatively short (roughly around 1000 lines or less would be ideal)
  • Well documented.

I recommend reading relatively short source code for two reasons. Firstly, short source code means readers don’t have to spend as much time navigating the source to connect the pieces. Secondly, readers can fully understand shorter code bases much faster than a framework that has 100,000 lines of code. Shorter code bases such as modules are compact. Readers only see what they need to see.(The Coding Delight, 2017)

Useful reads

Programming

UX / Design

Other resources

References

  1. u/ericsw & u/wseymour on reddit. (2017). How do you learn to write better/cleaner code? • r/learnprogramming. [online] Available at: https://www.reddit.com/r/learnprogramming/comments/69eexp/how_do_you_learn_to_write_bettercleaner_code/ [Accessed 8 May 2017].
  2. The Coding Delight. (2017). The 5 Effective Methods for Becoming a Better Programmer. [online] Available at: http://www.thecodingdelight.com/become-better-programmer/ [Accessed 17 Jun. 2017].

Fixes and notes for the future

  • Add few published sources to back up any statements I made or quoted from memory