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
234
235
236
237
238
239
|
<!-- <?xml version="1.0" ?>
<!DOCTYPE chapter PUBLIC "-//KDE//DTD DocBook XML V4.2-Based Variant V1.1//EN" "dtd/kdex.dtd">
To validate or process this file as a standalone document, uncomment
this prolog. Be sure to comment it out again when you are done -->
<chapter id="contributing">
<title
>Сотрудничество с &arts;</title>
<sect1 id="how-to-help">
<title
>Как вы можете помочь</title>
<para
>Помощь разработчикам заключается в адаптации существующих мультимедиа-приложений для работы с &arts;, создании новых приложений и расширении возможностей &arts;. Однако вам совсем необязательно быть разработчиком, чтобы помочь &arts;. Нам нужна помощь в тестировании (и написании отчётов об ошибках), переводе текстов и документации на различные языки, создании дизайна (особенно для модулей <application
>artsbuilder</application
>), музыканты могут написать примеры для модулей &arts;, а писатели - документацию. </para>
</sect1>
<sect1 id="mailing-lists">
<title
>Списки рассылок</title>
<para
>Большинство дискуссий разработчиков &arts; ведутся в двух рассылках. В этой обсуждаются новые функции, делятся мыслями и просят о помощи, если возникли проблемы. </para>
<para
>Рассылка <quote
>&kde; Multimedia</quote
> предназначена для обсуждения общих мультимедиа-приложений для &kde;, в том числе и &arts;, наряду с &noatun; и &aktion;. Вы можете подписаться на нее с сайта <ulink url="http://www.kde.org/mailinglists.html"
> http://www.kde.org/mailinglists.html</ulink
> или послать сообщение с темой <userinput
>subscribe <replaceable
>ваш-email-адрес</replaceable
></userinput
> на <email
>kde-multimedia-request@kde.org</email
>. Архив рассылки можно найти по адресу <ulink url="http://lists.kde.org"
> http://lists.kde.org</ulink
>. </para>
<para
>Рассылка для обсуждения вопросов об &arts;, в том числе и об использовании &arts; не в &kde;. Чтобы подписаться, пошлите сообщение с текстом<userinput
>subscribe <replaceable
>ваш-email-адрес</replaceable
></userinput
> на <email
>arts-request@space.twc.de</email
>. Архив рассылки можно найти по адресу <ulink url="http://space.twc.de/~stefan/arts-archive"
> http://space.twc.de/~stefan/arts-archive</ulink
>. </para>
</sect1>
<sect1 id="coding-standards">
<title
>Стандарты кодирования</title>
<para
>Чтобы можно было без лишних проблем читать разные исходные файлы, в них нужно использовать один стиль написания кода. Если вы просто пишете модуль, пожалуйста, постарайтесь писать код соответственно (или отформатируйте его), тогда разные люди смогут его дополнять или копировать его части. </para>
<variablelist>
<varlistentry>
<term
>Именование функций-членов</term>
<listitem>
<para
>Стиль &Qt;/&Java;. То есть каждое новое слово должно начинаться с заглавной буквы, но первое слово начинается со строчной, подчеркивания между словами не используются. </para>
<para
>Это значит, к примеру:</para>
<programlisting
>createStructureDesc()
updateWidget();
start(); </programlisting>
</listitem>
</varlistentry>
<varlistentry>
<term
>Члены класса</term>
<listitem>
<para
>Имена членов классов пишутся со строчной буквы: menubar, button. </para>
<para
>Если необходима функция доступа, лучше всего её писать в соответствии с &MCOP;, т. е. если есть функция-член <function
>foo</function
> типа long, которая не должна быть всегда видимой, вы пишете: </para>
<programlisting
>foo(long new_value);
long foo(); </programlisting>
<para
>функции получения и задания какого-либо значения. В этом случае, значение <function
>foo</function
> должно храниться в <returnvalue
>_foo</returnvalue
>. </para>
</listitem>
</varlistentry>
<varlistentry>
<term
>Имена классов</term>
<listitem>
<para
>В именах классов все слова должны начинаться с заглавной буквы, например, <classname
>ModuleView</classname
>, <classname
>SynthModule</classname
>. Все классы должны принадлежать библиотекам и использовать пространство имён &arts;, к примеру, <classname
>Arts::Soundserver</classname
>. </para>
<para
>Классы &MCOP; должны называться так:<classname
>Class_impl</classname
>, например, <classname
>SoundServer_impl</classname
>. </para>
</listitem>
</varlistentry>
<varlistentry>
<term
>Параметры</term>
<listitem>
<para
>Параметры всегда пишутся строчными буквами. </para>
</listitem>
</varlistentry>
<varlistentry>
<term
>Локальные переменные</term>
<listitem>
<para
>Локальные переменные всегда пишутся строчными буквами и могут называться <varname
>i</varname
>, <varname
>p</varname
>, <varname
>x</varname
> и т. д., если это не делает код трудночитаемым. </para>
</listitem>
</varlistentry>
<varlistentry>
<term
>Размер табуляции (отступы)</term>
<listitem>
<para
>Один уровень отступа равен 4 пробелам. </para>
</listitem>
</varlistentry>
<varlistentry>
<term
>Пробелы в выражениях</term>
<listitem>
<para
>Обычно вам не нужно использовать пробелы в выражениях. Хотя вы можете их вставлять между операторами и операндами. Однако, если вы набрали пробел перед оператором (например, +), нужно поставить его и после оператора. Единственное исключение - выражения с ",", в которых пробел нужно ставить после "," или вообще его опустить. </para>
<para
>Вот примеры правильного использования пробелов: </para>
<programlisting
>{
int a,b;
int c, d, e;
int f = 4;
a=b=c=d+e+f;
a = b = c = d + e + f;
if(a == 4) {
a = b = c = (d+e)/2;
}
while(b<3)
c--;
arts_debug("%d\n", c);
}
</programlisting>
<para
>А вот пример того, как <emphasis
>не нужно</emphasis
> ставить пробелы. В вызовах функций, после if, while, for, switch и т. д. пробелы не пишутся. </para>
<programlisting
>{
// ПЛОХО: в списке пробел ставится только после ","
int a , b , c , d , e , f;
// ПЛОХО: несимметричное использование пробела в операторе =
a= 5;
// ПЛОХО: if считается функцией, пробел не ставится
if (a == 5) {
}
// ПЛОХО: не пишите пробел после while
while (a--)
b++;
// ПЛОХО: после имён функций не надо ставить пробелы
arts_debug ("%d\n", c);
// ПЛОХО: не являются именами членов
Arts::Object o = Arts::Object::null ();
}
</programlisting>
</listitem>
</varlistentry>
<varlistentry>
<term
>Имена сходных файлов</term>
<listitem>
<para
>В названиях исходных файлов не должно быть заглавных букв. Они должны называться по имени реализуемого класса, если в них описывается только он один. Если файл содержит код, не зависящий от &Qt;/&GUI;, его расширением должно быть <literal role="extension"
>.cc</literal
>, иначе - <literal role="extension"
>.cpp</literal
>. Файлы, в которых реализуются интерфейсы, должны называться так: <filename
><replaceable
>foo</replaceable
>_impl</filename
>, если именем реализуемого интерфейса является Foo. </para>
<para
>Имена файлов &IDL; должны в достаточной мере описывать содержимое этих файлов и также не должны содержать заглавных букв. Не стоит называть файл по имени класса, так как информация о трейдере и типе в .mcopclass может перемешаться. </para>
</listitem>
</varlistentry>
</variablelist>
</sect1>
</chapter>
|
