Just as in a natural language there are issues of style on top of those of grammar, of orthography, and of syntax, there are issues of style in computer languages.

For example, in some languages, var = 3 sets var to 3, while var == 3 tests whether var is (already) equal to 3. Omit an = in a test, and the test accidentally becomes an assignment; many programs silently fail as a result of such an omission. But adopt the style of always putting any constant on the left side of the test (eg, 3 == var) and the error (eg, 3 = var, which attempts to set 3 to something) is noticed as soon as the compiler or interpetter reaches it. (There are compilers, interpretters, and separate utilities that will spot possible instances of errors of this sort. It's good to use tools with these features, but best not to be dependent upon them; and one doesn't want the notice of a genuine error to be lost in a sea of largely spurious warnings.)

The specifications of some computer languages, especially of those that are older, significantly limit the lengths of names and of labels; but it's otherwise stylistically best to chose names and labels that clearly identify the nature of whatever is named or labelled. Transparent names and labels then function as integrated documentation. One identifies a lazy or thoughtless programmer by the needless use of opaque names and labels. In Java, the stylistic convention is to name things in ways that clearly identify them; and the convention is to camel-case the names of variables, methods, and classes (eg, countOfBadBits); other languages also allow names to be clearly identifying, but the convention is to separate naming words with underscores (eg, count_of_bad_bits). One uses the naming convention that prevails amongst programmers of that language, so as not to throw-off other programmers who have to deal with the code; it is literally uncivil[1] to use the convention prevailing amongst programmers of one language when writing code in a language where a different convention prevails. (Had it been up to me, then we'd use a different naming style in Java; but it wasn't up to me and I abide by the prevailing convention.)

Many languages end statements with ;. When I helped other students debug SAS programs, I found that the error that they most often made was to omit that semicolon. Sometimes the program wouldn't compile, but sometimes it would compile and silently do something unintended. So I told them to put a space just before the semicolon. The program would still compile just fine if otherwise properly done; but, with all the semicolons visually floating instead of being up against something else, an omission would more easily be spotted. I don't myself use this style for every language in which it would work, but I adopt it for languages in which I notice myself or others omitting the semicolon.

(I was reminded of the general issue of coding style when working on some code written in Python, and wondering whether to put a space before each semicolon.)

[1] Civility is not conterminous with pleasantry; but, rather, a matter of behaving to avoid and to resolve conflict in interaction with other persons.