Opened 13 years ago
Closed 5 years ago
#7788 closed enhancement (fixed)
Create a Coding Guidelines application
Reported by: | mmadia | Owned by: | nobody |
---|---|---|---|
Priority: | normal | Milestone: | R1/beta2 |
Component: | Documentation | Version: | |
Keywords: | Cc: | ||
Blocked By: | Blocking: | ||
Platform: | All |
Description
While the Coding Guidelines cover most of the style format cases, they are discussed in isolation.
Having a working program (or group of source files) to act a working example of how to apply the coding guidelines could be useful. At all times, people could refer to that code to know how to format their code.
Change History (13)
comment:1 by , 13 years ago
follow-up: 3 comment:2 by , 13 years ago
I would like to have a script/application that can fix/warn those for me. I know/think that it exist some but don't know where to get them or how to use them. :D
follow-up: 4 comment:3 by , 13 years ago
Replying to axeld:
This sounds like a rather superfluous work, as we're open source, and have plenty of examples around already. Instead, I would look for an example in our sources, make sure it cover most cases, and bring it into shape if needed. And then only refer to that existing source in the coding style guide.
Point taken. Could someone make a short list of files (and their respective revision) to show all of the different cases in the coding style?
Having a concrete list of true-to-style code would be beneficial to anyone looking to become a regular patcher or hopeful committer.
Replying to modeenf:
I would like to have a script/application that can fix/warn those for me. I know/think that it exist some but don't know where to get them or how to use them. :D
This ticket is more about collecting a visual reference, than creating a program to reformat code. browser:haiku/trunk/src/tools/checkstyle is one of the python based tools. Though, it is not 100% accurate.
comment:4 by , 13 years ago
Replying to mmadia:
Having a concrete list of true-to-style code would be beneficial to anyone looking to become a regular patcher or hopeful committer.
The rule to be a perfect patcher is simple: first of all you should follow the coding guidelines and programming techniques used in the source(s) you are trying to patch. ;-)
comment:5 by , 13 years ago
Someone could probably tweak GNU Indent (or maybe BSD Indent) to format the files to the guidelines. The task involves choosing the right set of options to get the formatting correct ala -knr -ts4 etc. If that were done with any amount of accuracy then you could run the program as an SVN commit hook and we'd never have to talk about style issues ever again. :)
comment:6 by , 13 years ago
I don't understand why it is so hard to look at the coding guidelines page and see that we already have such a tool (as mmadia pointed) and that it is ridiculously easy to use. I personally don't need it or use it so i'm not very motivated to continue to work on it but it does the job decently if one dare's to try it. The code is very simple so please update it if something is missing or broken or create bug tickets.
comment:7 by , 13 years ago
btw sorry to derail the original ticket, to get back on track, i remember suggesting in the ml to simply provide one header and one cpp example file. Those don't need to be working or doing anything but i agree they would help to understand (too) short explanations or out of context excerpts.
comment:8 by , 10 years ago
Owner: | changed from | to
---|---|
Status: | new → assigned |
comment:10 by , 10 years ago
Owner: | changed from | to
---|
I'll take ownership of this one, although I'm not sure what course of action to take.
comment:11 by , 10 years ago
Milestone: | R1 → Unscheduled |
---|
comment:12 by , 10 years ago
Owner: | changed from | to
---|
Sending this one back to unassigned so somebody else can claim it.
comment:13 by , 5 years ago
Milestone: | Unscheduled → R1/beta2 |
---|---|
Resolution: | → fixed |
Status: | assigned → closed |
This sounds like a rather superfluous work, as we're open source, and have plenty of examples around already. Instead, I would look for an example in our sources, make sure it cover most cases, and bring it into shape if needed. And then only refer to that existing source in the coding style guide.