4 ms·

The purpose of code guidelines is to do exactly that: guide developers into a certain practice that’s consistent and broadly agreeable in a team setting. Using

The purpose of code guidelines is to do exactly that: guide developers into a certain practice that’s consistent and broadly agreeable in a team setting. Using lists to fake objects isn’t good modern style, and it’s a reasonable guideline to suggest not doing that. I’m sure Googlers won’t gripe if you temporarily cons up a list to shuttle it around. I’m sure they will gripe if you’re doing SICP 101 style object definitions exclusively with lists. The latter easily gets out of hand in a language renowned for its several robust facilities for object definitions. MAXIMA (née MACSYMA) is known for lists-as-objects not only being depended upon, but also getting so out of hand it’s nearly impossible to refactor now. MAXIMA at least has the excuse of being very old software. I feel you’re interpreting this style guide as some kind of draconian law of writing Lisp code at Google, and making awful conclusions from it (e.g., “well if you’re allergic to objects as lists might as well not use Lisp” or “most of this can be summed up as writing Lisp like Java”).

kazinator 6y ago
In my experience, these rules end up deployed in such a way that you cannot commit any change until they are obeyed to the letter. (That goes doubly so if they get encoded into an automated tool.) I don't disagree with that; a coding standard that is not enforceable without generous judgment calls is far less useful than a rigorous one. Make it exact, and then get everyone to stick to it.
- aidenn0 6y ago
  I have the exact opposite experience; my job with the favorite coding standard explicitly had ways of allowing variances. The CEO came down hard on anyone who said that "The standard forbids X" and would tell them to reread the standard because it actually said something like "Don't do X without doing Y first." The basic mentality was if you couldn't responsibly follow the style guidelines after working there for a year, then you should be looking for work elsewhere.

kazinator 6y ago

In my experience, these rules end up deployed in such a way that you cannot commit any change until they are obeyed to the letter. (That goes doubly so if they get encoded into an automated tool.) I don't disagree with that; a coding standard that is not enforceable without generous judgment calls is far less useful than a rigorous one. Make it exact, and then get everyone to stick to it.

aidenn0 6y ago
I have the exact opposite experience; my job with the favorite coding standard explicitly had ways of allowing variances. The CEO came down hard on anyone who said that "The standard forbids X" and would tell them to reread the standard because it actually said something like "Don't do X without doing Y first." The basic mentality was if you couldn't responsibly follow the style guidelines after working there for a year, then you should be looking for work elsewhere.