I do generally like the idea of a style guide, and I make an effort to follow the existing style guide in the manual. Maybe we should see which of John's proposals have wide appeal and add those to the existing style guide?
http://docs.julialang.org/en/latest/manual/style-guide/ For example, I think that 1-3 are logical (as a single item). I also like 6, 10-17, 21 (removing the ::Any part), 25-26. I have no opinion on 27-30. But the point I want to make is that there is probably a lot of stuff that would probably get a lot of consensus. Maybe it would be productive to identify which parts of John's proposal have broad agreement, add those to the manual, and argue about the rest later. Just an idea. I think there is much to like in John's proposal. Cheers, Daniel. On 31 December 2013 20:05, Spencer Russell <[email protected]> wrote: > On Tue, Dec 31, 2013 at 3:39 PM, Daniel Carrera <[email protected]> wrote: >> >> <snip> >> >> I don't think that argument holds water. At all. Google rules are not >> R rules, and R is not Julia. Companies and projects often have very >> specific style guides, while entire languages rarely do. > > > I think that style guidelines and coding standards are more common in > companies than language communities because they can enforce them. That > said, I think that PEP8 in the Python community is a great resource and the > fact that the community has a loose consensus to follow them makes working > in Python and contributing to Python projects easier. The standardization > also means that there's lots of tooling available that helps keep the style > consistent. > > If we can agree that in general having a more prescriptive style guide is a > good idea (which I'm guessing will need some more discussion), perhaps > discussion of individual rules would be better raised as issues and pull > requests in the repo? > > Hopefully once some consensus is reached the guidelines can be incorporated > into the existing Manual and eventually merged in to the docs at > http://docs.julialang.org/en/latest/manual/style-guide/ > > -s -- When an engineer says that something can't be done, it's a code phrase that means it's not fun to do.
