6 ms·

A guide for programming in style

13 points by reledi 13y ago

jcater 13y ago
What exactly are we looking at here? Someone's personal guide on getting their systems setup for development? An intro by a company for its new employees? Some new general manifesto a group thinks should apply to everyone? Some context would be nice.
- klibertp 13y ago
  It's important to realise that, whatever it is specifically, it's essentially just a bunch of personal preferences, unfounded beliefs and gut feelings. There are no facts at all when it comes to readability of code or code style. There was almost no research done and what was done is inconclusive. It's simply impossible to say with certainty whether any single style-guide is any better than any other. It's a real shame, because it makes people argue endlessly and spend precious time on writing this kind of "guides", which just fuel another pointless argument. For every single point in these guides there is a valid counterargument, as well as, of course, good reasons for it. I'm not academically prepared to do required research, but I certainly hope that someone will, preferably sooner than later. The fact that it wasn't done in the past 40 years makes me kind of pessimistic, though.
- reledi 13y ago
  The repository contains a bunch of guidelines that are maintained by the company thoughtbot. - A guide for programming well (guides/best-practices) - A guide for reviewing code and having your code reviewed (guides/code-review) - A guide for programming in style (guides/style) - Guides for getting things done (guides/protocol)
davecap1 13y ago
Any idea why the github wiki feature wasn't used for this?
- reledi 13y ago
  My guess is they wanted to use Pull Requests. Also, having the guides in READMEs makes them more visible since GitHub displays those automatically, whereas the wiki is a bit more hidden.
loqi 13y ago
It's a shame there's no accompanying rationale for any of these (cf. Google's C++ style guide [1]). Seems like a real challenge to maintaining relevant guidelines when change invalidates their underlying assumptions. [1]: https://google-styleguide.googlecode.com/svn/trunk/cppguide.xml https://google-styleguide.googlecode.com/svn/trunk/cppguide....

13 points by reledi 13y ago

What exactly are we looking at here? Someone's personal guide on getting their systems setup for development? An intro by a company for its new employees? Some new general manifesto a group thinks should apply to everyone? Some context would be nice.

klibertp 13y ago
It's important to realise that, whatever it is specifically, it's essentially just a bunch of personal preferences, unfounded beliefs and gut feelings. There are no facts at all when it comes to readability of code or code style. There was almost no research done and what was done is inconclusive. It's simply impossible to say with certainty whether any single style-guide is any better than any other. It's a real shame, because it makes people argue endlessly and spend precious time on writing this kind of "guides", which just fuel another pointless argument. For every single point in these guides there is a valid counterargument, as well as, of course, good reasons for it. I'm not academically prepared to do required research, but I certainly hope that someone will, preferably sooner than later. The fact that it wasn't done in the past 40 years makes me kind of pessimistic, though.
reledi 13y ago
The repository contains a bunch of guidelines that are maintained by the company thoughtbot. - A guide for programming well (guides/best-practices) - A guide for reviewing code and having your code reviewed (guides/code-review) - A guide for programming in style (guides/style) - Guides for getting things done (guides/protocol)

davecap1 13y ago

Any idea why the github wiki feature wasn't used for this?

reledi 13y ago
My guess is they wanted to use Pull Requests. Also, having the guides in READMEs makes them more visible since GitHub displays those automatically, whereas the wiki is a bit more hidden.

loqi 13y ago

It's a shame there's no accompanying rationale for any of these (cf. Google's C++ style guide [1]). Seems like a real challenge to maintaining relevant guidelines when change invalidates their underlying assumptions. [1]: https://google-styleguide.googlecode.com/svn/trunk/cppguide.xml https://google-styleguide.googlecode.com/svn/trunk/cppguide....