Personally, I do not think that a more thorough style guide is necessarily 
better. That said, I will give you my comments:

(4):  I like tabs and I use them.

(7) + (8):  I disagree. Although I generally use comma+space as you say, at 
times I deviate from that when I feel that doing so will improve the 
clarity and readability of my code.

(18)+(19):  I disagree. Although I could favour rules like this in a 
particular project, in many cases I think that adding type annotations just 
creates syntactic noise and can create a needless limitation.

(22)+(23)+(24): I do not think that performance tips belong in a style 
guide. You could spend a lot of time writing performance tips and I don't 
see an obvious reason why the three tips you chose are more important than 
other performance tips.

(31): I partially disagree. I like writing documentation (e.g. tutorial or 
explaining an algorithm) at the top of the file. I like having the 
documentation in the same file as the code that it refers to. I do not know 
what you mean when you say that "English documents are more readable when 
not constrained by the rule of code comments". What rules are those?

Also, I rarely want to have a diagram in my documentation because that 
involves starting a WYSIWYG program like LibreOffice or something like 
that. I haven't really felt a lot of need for diagrams.


(35): This doesn't sound like a style thing either. Advice on the correct 
way to use a module, or how to maintain precision or avoid round-off 
errors, do not belong in a style guide. This sort of thing belongs in 
either the documentation for the module, or on some tutorial about 
numerical computation.

Cheers,
Daniel.



On Tuesday, 31 December 2013 10:01:23 UTC-5, John Myles White wrote:
>
> One of the things that I really like about working with the Facebook 
> codebase is that all of the code was written to comply with a very thorough 
> internal style guideline. This prevents a lot of useless disagreement about 
> code stylistics and discourages the creation of unreadable code before 
> anything reaches the review stage. 
>
> In an attempt to emulate that level of thoroughness, I decided to extend 
> the main Julia manual’s style guide by writing my own personal style 
> guideline, which can be found at 
> https://github.com/johnmyleswhite/Style.jl 
>
> I’d be really interested to know what others think of these rules and what 
> they think is missing. Right now, my guidelines leave a lot of wiggle room. 
>
>  — John 
>
>

Reply via email to