Readability 1

Formatting your code

Don’t leave your code without any formatting, as it will be hard to read it again:

Picture of unformated code

Instead:

• Use line breaks & indentation
• Use * /* // for headings & comments
• Break code into multiple lines with /// or #delimit
• Agree with your team on a style

Picture of amended code

You can also use #delimit to change the meaning of line breaks.

Normally, line breaks mean the end of a command. With #delimit ; the semicolon means the end of the command, and you can use line breaks for formatting. #delimit cr changes this back to normal mode.

Picture of amended code

What’s considered “readable” varies immensely. Also, there might be trade-offs between what’s considered readable and what’s practical.

For example, some propose to never abbreviate commands. That’s something I personally wouldn’t consider as a huge increase in readability as the abbreviations are so common, and I would have to exert some effort to break my habit of using them. Others find it annoying to put white spaces between “=“, while I find they increase readability. Then again, some propose to keep do-files short and rather use many do-files, while others prefer having less files.

Always try to make your code readable for others. But: There’s no sense in setting standards if they are not followed through!