/usr/share/GNUstep/Documentation/Developer/CodingStandards/gs-standards/Coding-Style.html is in gnustep-base-doc 1.24.7-1.
This file is owned by root:root, with mode 0o644.
The actual contents of the file can be viewed below.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 | <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html>
<!-- Created by GNU Texinfo 5.2, http://www.gnu.org/software/texinfo/ -->
<head>
<title>Coding Standards for GNUstep Libraries: Coding Style</title>
<meta name="description" content="Coding Standards for GNUstep Libraries: Coding Style">
<meta name="keywords" content="Coding Standards for GNUstep Libraries: Coding Style">
<meta name="resource-type" content="document">
<meta name="distribution" content="global">
<meta name="Generator" content="makeinfo">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<link href="index.html#Top" rel="start" title="Top">
<link href="index.html#Top" rel="up" title="Top">
<link href="ObjectiveC.html#ObjectiveC" rel="next" title="ObjectiveC">
<link href="ChangeLog-Entries.html#ChangeLog-Entries" rel="prev" title="ChangeLog Entries">
<style type="text/css">
<!--
a.summary-letter {text-decoration: none}
blockquote.smallquotation {font-size: smaller}
div.display {margin-left: 3.2em}
div.example {margin-left: 3.2em}
div.indentedblock {margin-left: 3.2em}
div.lisp {margin-left: 3.2em}
div.smalldisplay {margin-left: 3.2em}
div.smallexample {margin-left: 3.2em}
div.smallindentedblock {margin-left: 3.2em; font-size: smaller}
div.smalllisp {margin-left: 3.2em}
kbd {font-style:oblique}
pre.display {font-family: inherit}
pre.format {font-family: inherit}
pre.menu-comment {font-family: serif}
pre.menu-preformatted {font-family: serif}
pre.smalldisplay {font-family: inherit; font-size: smaller}
pre.smallexample {font-size: smaller}
pre.smallformat {font-family: inherit; font-size: smaller}
pre.smalllisp {font-size: smaller}
span.nocodebreak {white-space:nowrap}
span.nolinebreak {white-space:nowrap}
span.roman {font-family:serif; font-weight:normal}
span.sansserif {font-family:sans-serif; font-weight:normal}
ul.no-bullet {list-style: none}
-->
</style>
</head>
<body lang="en" bgcolor="#FFFFFF" text="#000000" link="#0000FF" vlink="#800080" alink="#FF0000">
<a name="Coding-Style"></a>
<div class="header">
<p>
Next: <a href="ObjectiveC.html#ObjectiveC" accesskey="n" rel="next">ObjectiveC</a>, Previous: <a href="ChangeLog-Entries.html#ChangeLog-Entries" accesskey="p" rel="prev">ChangeLog Entries</a>, Up: <a href="index.html#Top" accesskey="u" rel="up">Top</a> </p>
</div>
<hr>
<a name="Coding-Style-1"></a>
<h2 class="chapter">3 Coding Style</h2>
<p>The point is not what style is ’better’ in the abstract – it’s what
style is standard and readily usable by all the people wanting to
use/work on GNUstep. A reasonably good consistent style is better for
collaborative work than a collection of styles irrespective of their
individual merits. If you commit changes that don’t conform to the
project standards, that just means that someone else will have a tedious
time making the necessary corrections (or removing your changes).
</p>
<p>The GNUstep coding standards are essentially the same as the GNU coding
standards (<a href="http://www.gnu.org/prep/standards_toc.html">http://www.gnu.org/prep/standards_toc.html</a>), but here
is a summary of the essentials.
</p>
<p>White space should be used for clarity throughout. In particular,
variable declarations should be separated from code by a blank line and
function/method implementations should be separated by a blank line.
</p>
<p>Tabs should not be used (use spaces instead). If you do use them
(please don’t) they really, really, must be for tab-stops at the
standard intervals of 8 spaces.
</p>
<p>All binary operators should be surrounded by white space with the
exception of the comma (only a trailing white space), and the
<code>.</code> and <code>-></code> structure member references (no space).
</p><div class="example">
<pre class="example">x = y + z;
x += 2;
x = ptr->field;
x = record.member;
x++, y++;
</pre></div>
<p>Brackets should have space only before the leading bracket and after
the trailing bracket (as in this example), though there are odd occasions
where those spaces might be omitted ((eg. when brackets are doubled)).
This applies to square brackets too.
</p>
<p>Where round brackets are used to enclose function or macro paramters, there
is no space between the function romacro name and the opening bracket, and
where round brackets are used for type-casts or at the end of a statement,
there is normally no space between the closing bracket and the following
expression or semicolon-
</p><div class="example">
<pre class="example">a = (int)b;
- (void) methodWithArg1: (int)arg1 andArg2: (float)arg2;
a = foo(ax, y, z);
</pre></div>
<p>The placement of curly brackets is part of the indentation rules. the
correct GNU style is to indent by two spaces
</p><div class="example">
<pre class="example"> if (...)
{
...
}
</pre></div>
<p>For function implementations, the function names must begin on column zero
(types on the preceding line). For function predeclaration, the types and
the name should appear on the same line if possible.
</p><div class="example">
<pre class="example">static int myFunction(int a, int b);
static int
myFunction(int a, int b)
{
return a + b;
}
</pre></div>
<p>The curly brackets enclosing function and method implementations should be
based in column 0. Indentation is in steps of two spaces.
</p><div class="example">
<pre class="example">int
myMax(int a, int b)
{
if (a < b)
{
return b;
}
return a;
}
</pre></div>
<p>Lines longer than 80 columns must be split up, if possible with the
line wrap occurring immediately before an operator. The wrapped lines
are indented by two spaces form the original.
</p><div class="example">
<pre class="example"> if ((conditionalTestVariable1 > conditionaltestVariable2)
&& (conditionalTestvariable3 > conditionalTestvariable4))
{
// Do something here.
}
</pre></div>
<p>Some things the standards seem to think are ’should’ rather than ’must’:
</p>
<p>Multiline comments should use <code>/* ... */</code> while single line
comments may use <code>//</code>.
</p>
<p>In a C/ObjC variable declaration, the ‘<samp>*</samp>’ refers to the variable,
not to the type, so you write
</p><div class="example">
<pre class="example"> char *foo;
</pre></div>
<p>not
</p><div class="example">
<pre class="example"> char* foo;
</pre></div>
<p>Using the latter approach encourages newbie programmers to thing they can
declare two pointer variables by writing
</p><div class="example">
<pre class="example"> char* foo,bar;
</pre></div>
<p>when of course they need
</p><div class="example">
<pre class="example"> char *foo, *bar;
</pre></div>
<p>or (in my opinion better)
</p><div class="example">
<pre class="example"> char *foo;
char *bar;
</pre></div>
<p>An exception to the indentation rules for Objective-C: We normally don’t
break long methods by indenting subsequent lines by two spaces, but make the
parts of the method line up instead.
The way to do this is indent so the colons line up.
</p><div class="example">
<pre class="example"> [receiver doSomethingWith: firstArg
and: secondArg
also: thirdArg];
</pre></div>
<p>That’s the style used mostly in the GNUstep code - and therefore the one I
try to keep to, however, the standard two space indentation is also acceptable
(and sometimes necessary to prevent the text exceeding the 80 character line
length limit).
</p><div class="example">
<pre class="example"> [receiver doSomethingWith: firstArg
and: secondArg
also: thirdArg];
</pre></div>
<p>My own preference (not part of the standard in any way) is to
generally use curly brackets for control constructs, even where only one line
of code is involved
</p><div class="example">
<pre class="example"> if (a)
{
x = y;
}
</pre></div>
<p>Where using conditional compilation you should comment the #else and #endif
with the condition expression used in the #if line, to make it easy to find
the matching lines.
</p><div class="example">
<pre class="example">#if condition
// some code here
#else /* not condition */
#endif /* condition */
</pre></div>
<hr>
<div class="header">
<p>
Next: <a href="ObjectiveC.html#ObjectiveC" accesskey="n" rel="next">ObjectiveC</a>, Previous: <a href="ChangeLog-Entries.html#ChangeLog-Entries" accesskey="p" rel="prev">ChangeLog Entries</a>, Up: <a href="index.html#Top" accesskey="u" rel="up">Top</a> </p>
</div>
</body>
</html>
|