Acknowledge the definition of "too long" for a variable name is tricky to get right. Try to find some useful heuristic.
Make sure to note the mutate! and ispredicate conventions.
Note that Julia functions should usually be called verb_noun rather than noun_verb
Insert the following text regarding comments:
Source comments
Avoid overcommenting: Architectural explanations and descriptions of
math formulas are important, but should be kept in a separate file.
Avoid undercommenting: Explain the purpose of each function, the
meaning of each argument (unless they are truly self-evident), and
every pattern that is not truly transparent.
The goal is to strike a balance between keeping the documentation
updated, and minimizing the clutter inside source files. In general,
explanations tightly coupled to the code should be in the code and
explanations that are detached from the code should be outside the
code.
Change the rule requiring that lines be 80 characters at most to a suggestion to avoid overly long lines. Reference PEP8, which contains the following text:
"Some teams strongly prefer a longer line length. For code maintained exclusively or primarily by a team that can reach agreement on this issue, it is okay to increase the nominal line length from 80 to 100 characters (effectively increasing the maximum length to 99 characters), provided that comments and docstrings are still wrapped at 72 characters."
Allow the use of spaces or no spaces when using keyword arguments.
Comment every function with text describing a function's purpose.
Note that ambiguity warnings can always be avoided by ordering methods from most to least specific, but not the other way around. But also note that that it's often nice to read the most general cases first.
Remove rule disallowing
for x = y
.Remove rule requiring explicit
Any
.Try to develop a
go fmt
tool for Julia.Acknowledge the definition of "too long" for a variable name is tricky to get right. Try to find some useful heuristic.
Make sure to note the
mutate!
andispredicate
conventions.Note that Julia functions should usually be called
verb_noun
rather thannoun_verb
Insert the following text regarding comments:
Source comments
Avoid overcommenting: Architectural explanations and descriptions of math formulas are important, but should be kept in a separate file.
Avoid undercommenting: Explain the purpose of each function, the meaning of each argument (unless they are truly self-evident), and every pattern that is not truly transparent.
The goal is to strike a balance between keeping the documentation updated, and minimizing the clutter inside source files. In general, explanations tightly coupled to the code should be in the code and explanations that are detached from the code should be outside the code.
Change the rule requiring that lines be 80 characters at most to a suggestion to avoid overly long lines. Reference PEP8, which contains the following text:
"Some teams strongly prefer a longer line length. For code maintained exclusively or primarily by a team that can reach agreement on this issue, it is okay to increase the nominal line length from 80 to 100 characters (effectively increasing the maximum length to 99 characters), provided that comments and docstrings are still wrapped at 72 characters."
Allow the use of spaces or no spaces when using keyword arguments.
Comment every function with text describing a function's purpose.
Note that ambiguity warnings can always be avoided by ordering methods from most to least specific, but not the other way around. But also note that that it's often nice to read the most general cases first.