[Oberon-07] Руководство по стилю кодирования

[Geniepro]

http://oberspace.dyndns.org/index.php/topic,541.msg18024.html#msg18024

Этот

В общем и в целом нормально, суть руководства по стилю ухвачена.

Но есть претензии:

1) Аргументы процедур надо отделять друг от друга пробелами:

Правильно:

PROCEDURE Line*(x0, y0, x1, y1 : REAL);

P.SetSize(640, 360);

Неправильно:

PROCEDURE Line*(x0,y0,x1,y1 : REAL);

P.SetSize(640,360);

2) Операторы в выражениях так же следует отделять от их аргументов пробелами:

Правильно:

h := 0.66 * h;

Неправильно:

h := 0.66*h;

3) Не знаю, как лучше делать в таких случаях:

так:

Код: [Выделить]

  TYPE
    ProcessingType* = POINTER TO RECORD END; (* dummy type *)
    CallbackType*   = PROCEDURE;
  VAR
    MouseX*   : REAL;
    MouseY*   : REAL;
    Width*    : INTEGER;
    Height*   : INTEGER;или так:

Код: [Выделить]

  TYPE
    ProcessingType * = POINTER TO RECORD END; (* dummy type *)
    CallbackType   * = PROCEDURE;
  VAR
    MouseX  * : REAL;
    MouseY  * : REAL;
    Width   * : INTEGER;
    Height  * : INTEGER;или даже так:

Код: [Выделить]

  TYPE
    ProcessingType *= POINTER TO RECORD END; (* dummy type *)
    CallbackType   *= PROCEDURE;
  VAR
    MouseX   *: REAL;
    MouseY   *: REAL;
    Width    *: INTEGER;
    Height   *: INTEGER;

[igor]

3) Не знаю, как лучше делать в таких случаях:

На мой взгляд, лучше первый вариант. Во втором варианте звёздочка выглядит как "умножить" и только сбивает с толку. Третий вариант тоже плох, потому что маркер семантически связан с идентификатором, а не с типом. Стремление представить инфу об экспорте в виде столбика понятно, - так нагляднее, - но здесь всё же лучше не перебарщивать.

[Geniepro]

3) Не знаю, как лучше делать в таких случаях:

На мой взгляд, лучше первый вариант. Во втором варианте звёздочка выглядит как "умножить" и только сбивает с толку. Третий вариант тоже плох, потому что маркер семантически связан с идентификатором, а не с типом. Стремление представить инфу об экспорте в виде столбика понятно, - так нагляднее, - но здесь всё же лучше не перебарщивать.

В первом варианте тоже недостаток -- эта звёздочка экспорта плохо заметна. Если бы хотя бы она была перед идентификатором...
И вообще, что мешало Вирту ввести ещё одно ключевое слово public? Если он стремился к ясности программ на своём языке, то не стоило так экономить на спичках -- только хуже получилось...

[adva]

И вообще, что мешало Вирту ввести ещё одно ключевое слово public?

А если это слово в комментарии указать, не равнозначно будет?

[Geniepro]

И вообще, что мешало Вирту ввести ещё одно ключевое слово public?

А если это слово в комментарии указать, не равнозначно будет?

Нет, ведь комментарии необязательны, а значит реально мало кто будет указывать.

[Geniepro]

Народ, гляньте мой Оберонистый код, и напишите список замечаний по стилю плиз.

Кстати да, комментариев вапще недостаточно )))

[Jordan]

И вообще, что мешало Вирту ввести ещё одно ключевое слово public?

Всё это расширизмы и непотребство.

И вообще, что мешало Вирту ввести ещё одно ключевое слово public?

А если это слово в комментарии указать, не равнозначно будет?

Как раньше на паскале?

end (* имя функции*);

while

end (* while*) и т.д

  TYPE
    ProcessingType * = POINTER TO RECORD END; (* dummy type *)
    CallbackType     * = PROCEDURE;
  VAR
    MouseX  * : REAL;
    MouseY  * : REAL;
    Width     * : INTEGER;
    Height    * : INTEGER;

Я голосую за этот вариант.

[igor]

  TYPE
    ProcessingType * = POINTER TO RECORD END; (* dummy type *)
    CallbackType     * = PROCEDURE;
  VAR
    MouseX  * : REAL;
    MouseY  * : REAL;
    Width     * : INTEGER;
    Height    * : INTEGER;

Я голосую за этот вариант.

А если я хочу так записать:

  VAR
    MouseX*, MouseY* : REAL;   (* позиция курсора мыши *)
    Width*, Height* : INTEGER;  (* размеры окна *)

, то как мне отступы делать?

[Geniepro]

А если я хочу так записать:

Код: [Выделить]

  VAR
    MouseX*, MouseY* : REAL;   (* позиция курсора мыши *)
    Width*, Height* : INTEGER;  (* размеры окна *)
, то как мне отступы делать?

Да, вопрос, конечно, интересный.
Можно было бы, конечно, так:

Код: [Выделить]

  VAR
    MouseX * : REAL;     (* позиция курсора мыши -- координата X *)
    MouseY * : REAL;     (* позиция курсора мыши -- координата Y *)
    Width  * : INTEGER;  (* размеры окна -- ширина *)
    Height * : INTEGER;  (* размеры окна -- высота *)
Такие вопросы, как количество переменных в одной строке списка экспорта, тоже надо рассмотреть и к какому-то соглашению прийти...

[igor]

Такие вопросы, как количество переменных в одной строке списка экспорта, тоже надо рассмотреть и к какому-то соглашению прийти...

В приведённых примерах координаты (или там размеры) относятся к одной сущности (курсор мыши), поэтому их разделять не целесообразно. Большой беды, конечно, не будет, если их записать на разных строчках, но слишком уж утомительно подробно получается (даже комментарии частично дублируют друг друга).

[Geniepro]

Такие вопросы, как количество переменных в одной строке списка экспорта, тоже надо рассмотреть и к какому-то соглашению прийти...

В приведённых примерах координаты (или там размеры) относятся к одной сущности (курсор мыши), поэтому их разделять не целесообразно. Большой беды, конечно, не будет, если их записать на разных строчках, но слишком уж утомительно подробно получается (даже комментарии частично дублируют друг друга).

Такие связанные сущности принято объединять в структуры (записи), вообще-то...

[vlad]

Такие связанные сущности принято объединять в структуры (записи), вообще-то...

Я бы вообще предложил запретить нотацию "через запятую". Даже для связанных сущностей. А не связанные сущности отделять пустой строкой. Стремление в обероновских исходниках все упрятать в  одну строку никогда не радовало глаз...

P.S. В С тоже можно лепить поля через запятую. В итоге во всех вменяемых исходниках это не практикуется.

[valexey_u]

Предлагаю использовать отступ либо в 3 пробела (как в Аде) либо вообще в 4 - во-первых в этом случае отступы видны лучше, во-вторых в этом случае уровень вложенности конструкций будет получаться меньше.

[vlad]

Предлагаю использовать отступ либо в 3 пробела (как в Аде) либо вообще в 4 - во-первых в этом случае отступы видны лучше, во-вторых в этом случае уровень вложенности конструкций будет получаться меньше.

Я за 4.

[Geniepro]

Предлагаю использовать отступ либо в 3 пробела (как в Аде) либо вообще в 4 - во-первых в этом случае отступы видны лучше, во-вторых в этом случае уровень вложенности конструкций будет получаться меньше.

Я за 4.

А может сразу 8 -- как в линуксе? И вапще не пробелы, а табуляцию? ))) Вложенность больше 3 будет трудно создавать при ограничении в 80 символов в строке )))