Change a variable name, yes absolutely depending on context and the language in use, this can range from using foo_bar&#x2F;fooBar through to inappropriate variable names (I&#x27;ve seen swearwords used as variables when someone has been doing debugging in code and needed to grab intermediate values, seeing &quot;cunt is undefined&quot; in the console is not going to do you any favours on the professional scale) or ones that lack clarity.<p>Prohibit lines longer than N chars, again absolutely, many languages have standards like Pythons PEP8, I find 80 chars constricting sometimes but I stick to the standard because it is the standard (de-facto or not).<p>--<p>I stick to standards where they exist, for PHP thats the relevant PSR&#x27;s, for Python, PEP8.<p>I enforce it by using the IDE to flag non-conformance and auto format either on the fly or on save, since I&#x27;m the only dev I don&#x27;t need to enforce it on commits&#x2F;pull requests.<p>Style Reviews are not applicable since there is just me (see above).<p>I think coding against the languages &#x27;default&#x27; styles whether de-facto or imposed (I wish all languages had gone the gofmt route so we could obviate this problem nearly completely) helps, it certainly requires less context shifting when jumping from code I wrote to third party libraries in the same language.<p>In the past when I&#x27;ve worked with teams I&#x27;ve found having a defined standard helps hugely since it settles the inevitable bikeshedding arguments that crop up when programmer A wants to do foo and B do bar, often there is no clear winner so just picking one and adding it to the standard kills the argument dead the next time.<p>Personally I&#x27;ve always preferred :-<p><pre><code>    if foo()
    {
        stuff();
    }
</code></pre>
to<p><pre><code>    if foo(){
        stuff();
    }
</code></pre>
but since PSR2 says not to do that I stopped (or more correctly I let the IDE handle it till it became habit to do it PSR style).