Rules to Better Code

What makes code "cleaner"? What makes the difference between readable code and very readable code?

It can be very painful when needing to modify a piece of code in an application that you never spec'd out or wrote. But it doesn't have to be this way. By following some of these better programming tips your code can be easily read and easily modified by any developer at any time.

  1. Refactoring is all about making code easier to understand and cheaper to modify without changing its behavior.

  2. You should generally be looking for ways to simplify your code (e.g. removing heavily-nested case statements). As a minimum, look for the most complicated method you have and check whether it needs simplifying.

    In Visual Studio, there is built-in support for Cyclomatic Complexity analysis.

  3. Too often, developers are writing a line of code, and they forget that little bit of syntax they need to do what they want. In that case, they usually end up googling it to find the documentation and then copy and paste it into their code. That process is a pain because it wastes valuable dev time. They might also ask another dev for help.

    Not to worry, AI pair programming is here to save the day!

  4. Code duplication is a big "code smell" that harms maintainability. You should keep an eye out for repeated code and make sure you refactor it into a single place.

  5. One of the major issues people had back in the day with ASP (before ASP.NET) was the prevalence of "Spaghetti Code". This mixed Reponse.Write() with actual code.

  6. When moving through the different stages of testing i.e. from internal testing, through to UAT, you should suffix the application name with the appropriate stage:

  7. It is not a good idea to have spaces in a folder or file name as they don't translate to URLs very well and can even cause technical problems.

    Instead of using spaces, we recommend:

    • kebab-case - using dashes between words

    Other not recommended options include:

    • CamelCase - using the first letter of each word in uppercase and the rest of the word in lowercase
    • snake_case - using underscores between words

    For further information, read Do you know how to name documents?

  8. Try to avoid problems in if-statements without curly brackets and just one statement which is written one line below the if-statement. Use just one line for such if-statements. If you want to add more statements later on and you could forget to add the curly brackets which may cause problems later on.

  9. Try to avoid Double-Negative Conditionals in if-statements. Double negative conditionals are difficult to read because developers have to evaluate which is the positive state of two negatives. So always try to make a single positive when you write if-statement.

  10. Strings should be @-quoted instead of using escape character for "\". The @ symbol specifies that escape characters and line breaks should be ignored when the string is created.

per page
1 - 10 of 81 items
We open source.Loving SSW Rules? Star us on GitHub. Star