TL;DR code linters may be beneficial but may also cause problems. Basically:
- It should be included in the editor plugins and shared as most as possible. Example: I never have to complain when vim reformat my Go source file upon saving it. I did not configure it either, it was automatic.
- automated tools cannot evaluate code complexity, only give metrics that may or may not represent complexity
- code complexity depends on how people read the code
Code is complex when understanding what it does, reading it, becomes complex. Thus it depends on how people are reading the code. One thing that makes code complex is when you have to browse to different locations/files when reading the code. Another thing that makes reading difficult is when code is not well organized and you struggle to find a piece of code.
I am a person that when reading the code, needs to ensure that every function encountered is known. I almost never trust function names to do what they are named after. Instead I will, most of the times, find the function definition and read the code to be sure about what it does. If it is an external library I may only read the documentation. If I remember from before what the function does, I will not have to look at it, but depending on the number of external functions, I may need to maintain quite a long list of functions in my brain memory.
I find that I am comfortable with code that contain function that are either very small (2 lines max) or relatively long. A long function can be read like a book and you do not need to skip to other parts of the file to read the code in full. I often find a pattern that I find really hard : small functions, 5 to 10 lines, cross referenced together. The functions are not complete in isolation and must be understood within the larger algorithm. In those cases I prefer a large function that does everything. Not only reading can happen in order and not out of order, but you don't need to check every time you need to change the function signature that there are no other call sites.
Basically, a good rule is to try to document the function with all its edge cases and the data types it uses. If the description is longer than the function itself, you have a problem. This is not an isolated function but a part of an algorithm that cannot be split. If you can imagine yourself taking the function and putting in an utility package where you have no specific data types, it means this is a good isolated function.
These are generally rules to avoid complex code. However complexity is not so simple to measure. Yoiu can have a 100 line function very simple to understand (a gigantic conversion switch) and a 5 line function very complex (two loops with 3 helper functions).
The good rules to have if you want to measure that kind of thing is to measure:
- the mean function length
- the mean number of function per unit of code
- the mean number of files per module
- ...
And what is most important there is to measure trends.
I often saw linters that mandates the use of so-called single quotes for all strings. Using 'blah' instead of "blah". Of course, it depends on the language itself, but often single quotes do not allow interpolation within when double quotes can.
- if the reason of this rule is to make processing faster by not having interpolation, the parser do not care and this is just not a good reason
- if the reason is that you could have interpolated strings by mistake, can you point a single bug that was caused by that? Generally interpolation syntax is special and do not occur in strings by mistake, and you have syntax highlighting in your editor, right?
- if the reason is that the strings may contain double quotes, so you must enclose it within simple quotes, the answer is yes, but not always. The programmer should have the final word in deciding what kind of quotes to use and not be bothered by an error firing over this
In deciding which kind of quotes to use, the best rule is to choose by which quotes is going to reduce the amount of escape sequences, now and during the lifetime of the string. Basically:
- if the text is expressed in a natural language, and because text can often contain the quote character
', the string should be in double quotes, always. Even if your text do not contain right now the quote character. Because the text may change at some point and when the wording will be changed to include a quote, the person making the change will have to change the string quotes as well. - if you enclose XML or HTML which can contain attribute values, you should use double quotes
- if your text contains the character used for text interpolation, a non interpolating string should be used
- if none of this applies, nobody should care. I have a personal preference for double quotes because this is the character that is used in the natural languages to express text quoting.
If I include a space here and there. Do I have parenthesis in that case. Do I have a trailing comma in lists, semicolons, ... those rules are pure syntax rules. I couldn't care less and the last thing I want is to be bothered at a later stage, during code review for example, because of this. If these rules are important the compiling toolchain should automatically apply them and modify the source code accordingly. The go language does that and it works well. Those are rules that suffer no exception. Be careful not to limit the language expressiveness using that.