Developers should be in the habit of using spaces instead of tabs to indent and indicate structure in their code. Different editors can interpret tabs differently and give the white space they represent a different width. Code that is indented one way for a developer might appear differently on another developer's computer. This is especially a problem when there is a mix of tabs and spaces leading to indentation of lines can become really out of hand. One area where we had issues was with our code review tool Review Ninja which had a wider interpretation of tabs. This caused lines of code prefixed with tabs to seem more intended that lines with spaces. Reviewing code was much harder since lines would be randomly indented and it would be more difficult to read the structure of our code.
Most editors use a monospace font so spaces are always the same size as all the other characters and everything is kept in proportion. We established a convention of indenting lines with 4 spaces, which is pretty standard. Most text editors can be configured to insert tabs in the place of spaces. In Notepad++ simply navigate to
Settings>Preferences...>Tab Settings and check
Replace by space.
Another quality issue that falls into this category of whitespace management is trailing whitespaces. They are useless and could cause issues when comparing versions of code as shown in the image below. The conversion of tabs into spaces and the removal of trailing whitespaces can be easily automated. In our project, since we only had a few files, I would manually open each file and apply the "TAB to Space" and "Trim Trailing Space" under "Edit->Blank Operations" in Notepad++ at the end of each Sprint to remove any whitespace problems that managed to sneak their way into our code.
==) and triple equals (
===). Programmers are often familiar with writing
== from other programming languages and end up using the same
=== that exhibits equality checking behaviour closest to the
=== checks if two variables are of the same type and the same value. When
== is used, if the variables are not of the same type, it will attempt to cast them to the same type so that their values can be compared. This casting operation may produce unexpected results and not cast our variable to a value that is appropriate for comparisons.
=== since this will behave like they are used to from other programming languages. If using a
=== doesn't work while using
== does work, there is probably something wrong with your code where you end up comparing variables of different types. An example from our project was a case where we were checking the equality between two variables storing an id number. The variables where never equal when using
===, but switching it to
== worked as expected. The issue originated from an id value that was extracted from a string but never converted to an integer. Therefore, the equality check was comparing an id number with another id number but encoded as a string. Although this section of the code worked when using
=== allowed us to notice our oversight, program the code to execute as we expected it too, and also to avoid further errors later in the code.
A pretty big pet peeve of mine is to leave commended out code trailing around. I always recommend to use Git for even small projects which allows referencing previous versions of one's software. If you wish to archive something, commit what you have, then remove the commented code or any code you don't need in the foreseeable future, then commit your clean and shiny non-commented out code :)
Programmers sometimes like to leave comments prefixed with TODO to indicate work that needs to be done inside the actual code itself. This is a very messy way of keeping track of what needs to be done and you should consider using a task or project management system. If something still needs to be done submit a ticket in your management software and. For our project in particular using TODO comments ways particularly gnarly since we were already using JIRA for task management. My compromise to the team was to resolve any TODO comments they generated by the end of the Sprint to avoid the technical debt created from combing through the code and evaluating TODO comments against tasks in JIRA.