Skip to main content
4 events
when toggle format what by license comment
May 30, 2016 at 10:39 comment added Adriano Repetti BTW if, instead, you suggest to do not write down only code formatting styles then I may agree (well, actually not but with not so strong reasons besides memories of endless and useless discussions that will inevitably arise each time - and which a corporate guideline will avoid once for all) however you should make it clear or people will interpret your words too literally (see most of answers + comments here). Also that point about "goto" is little bit misleading in this sense (IMO)
May 30, 2016 at 9:00 comment added Adriano Repetti 3) Code may tell you what to do but it can't convey what you should not do (unless you want to study whole code base and even in that case...just didn't happen to have to use X construct or it's a no-no?) Another important thing is the reasoning: why not? and why yes? Things may change over time but how you know if initial premises are still valid? 4) and when you're a new team member and you write new code...do you study code base with same age to keep that coding style? The day after you move to another newer component and you study codebase again (filtering by creation date?)
May 30, 2016 at 8:55 comment added Adriano Repetti I have few perplexities: 1) to be useful a coding standard shouldn't talk only about formatting (matter of holy wars but easy to understand reading code) but constructs to avoid, coding patterns (to prevent common mistakes, not easy to understand language features) and security issues. These are coding guidelines (more useful than formatting issues). 2) Given the premise of point 1 then it's not about personality (but it may be about tasks), you can have a lightweight corporate standard, it's your own duty to make it lightweight.
May 27, 2016 at 7:56 history answered Robert Martin CC BY-SA 3.0