Оптимзация кода

[ds.Dante]

Сообщение от Gregor

а что думаете по поводу нигде неиспользуемых функций и классов?

Закомментируй, потом видно будет.

Сообщение от Gregor

Вот вспомнил книжку Макконнелла «Совершенный код» стр 169. как раз про это

Если ты единственный в команде, кто читает такую литературу, то нафиг такую команду.

[Alex11223]

чем в твоем случае обусловлен префикс A в параметре функций?

В Дельфях А многие используют в параметрах (типа Argument видимо) потому что имена не регистрозависимы и часто нет других вариантов например когда есть свойство в классе с таким именем. (в C# обычно свойства UpperCase, а параметры lowerCase)

[min@y™]

чем в твоем случае обусловлен префикс A в параметре функций? я раньше тоже так делал что бы отличить параметры от локальных переменных

Именно так!

но пришлось принять правила команды.

Переходи в мою команду. Как тебе мой кодЪ? В глазах не рябит? Читабельно?

[Gregor]

Читабельно! Очень даже. Как связаться?

[min@y™]

Как связаться?

с кем?

[Gregor]

Сообщение от min@y™

Именно так!

Переходи в мою команду.

Это как понимать? )

[min@y™]

Это как понимать? )

про команду - шутка.
я всегда работаю один.

[Вадим Мошев]

Сообщение от min@y™

могу показать, как пишу код я. Вдруг понравится?

Посмотрел я код. Красиво и понятно оформлено, мне нравится. Я его пробежал по диагонали и понял, что я даже хеллоувордщиком, наверное, не являюсь. Хотя...

Можно я немного позадаю вопросов и покритикую, именно оформление и форматирование, а не логику?

На чём остановился взгляд.

if AAutoAppend      // добавление в конец списка,
             then begin
                    Add(Result); // если надо
                    FModified:= True; // todo: перекрыть методы Add, Insert, Delete и т.п. ???
                  end;

Я бы всё-таки советовал (у меня это вошло уже в привычку) использовать скобки (в данном случае begin/end) именно в египетском стиле. То есть,

if condition then begin

  for i:=start to finish do begin

    while someState do begin
    end;
    
  end;

end;

Потом, у тебя идентификаторы (я говорю не о тех, к которым применена венгерская нотация) начинаются с большой буквы. Я понимаю, есть разные варианты записи имён идентификаторов, но если ты используешь camelCase, то начинать следует с малой буквы.

Далее:

if (AOperation in MEMORY_WRITE_OPERATIONS) and Assigned(pmcci) and pmcci.InitByZeroes
             then TMemoryCommand(Result).ZeroItems();

Об этом gunSmoker писал. Если условие составное, и его запись достаточно длинная, то условие стоит разбивать на несколько строк, каждая их которых заканчивается обозначениям логической операции. В твоём случае код выглядел бы так:

if (AOperation in MEMORY_WRITE_OPERATIONS) and
   Assigned(pmcci) and pmcci.InitByZeroes then begin

    TMemoryCommand(Result).ZeroItems();

end;

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

Далее:

function TCommandQueue.GetEmpty: Boolean;
begin
  Result:= Count = 0;
end;

По-моему мнению, имена методов следует выбирать таким образом, чтобы оно формировало фразу, связанную с действием/результатом метода.
Например, метод, который получает простых чисел, я бы назвал getPrimeNumbersAmount (get - получить).
Метод, который сбрасывает состояние некоторых объектов по умолчанию, я бы назвал resetToDefault.

Также и с логическими методами (как у тебя). Из название должно представлять собой утверждение (или вопрос), которое может быть как ИСТИННЫМ, так и ЛОЖНЫМ (в случае с вопросом, ИСТИНА или ЛОЖЬ являются на него ответами). Например, массив, который проверяет, есть ли нули в массиве, можно назвать так: arrayHasZeros. Кстати, в коде такое будет очень красиво читаться:

if arrayHasZeros(<что-то>) then...

То есть, получаем предложение, которое записано чуть ли не на человеческом языке.

Вернёмся к твоему случаю. Я бы назвал метод: isQueueEmpty (ты же очередь проверяешь на пустоту)? То есть, "Пуста ли очередь?"

[Utkin]

могу показать, как пишу код я. Вдруг понравится?

Одобрямс, только я еще визуально функции слешеками друг от друга отделяю - и смотрится красиво и искать быстрей.

Кстати, я бы рекомендовал использовать составной оператор всегда, даже если внутри всего один оператор.

Угум, хоть цикл, хоть условие даже с одним оператором и одной ветвью - всегда оформляю begin-end.

[min@y™]

Я бы всё-таки советовал (у меня это вошло уже в привычку) использовать скобки (в данном случае begin/end) именно в египетском стиле.

Ну, а я вот именно так пишу. Почему так сложилось - не помню, но привык с самого начала 90х годов так писать.

но если ты используешь camelCase, то начинать следует с малой буквы.

Не знаю, что такое camelCase, но я стараюсь выбирать имена идентификаторов примерно так (но не всегда):
* константы - ЗАГЛАВНЫМИ;
* локальные переменные:
- все строчные, если одно слово (temp, lines и т.п.), или с заглавной (реже, в зависимости от контекста, погоды на марсе, фазы Луны и т.п.);
- из нескольких слов - всегда каждое с заглавной (локальные переменные с такими именами применяю редко, только по необходимости);
- никогда (!!!) не использую однобуквенные идентификаторы, даже параметры циклов и индексы массивов именую Index или idx. Настоятельно советую делать также.
* типы/классы - естественно с буквы "Т";
* формальные параметры - с буквы "А" (в большинстве случаев);
* поля записей и классов - с буквы "F";
* поля-ссылки на внешние объекты - с буквы "L" (придумал недавно);

function TCommandList.SaveAs: Boolean;
begin
  { "L" ---> } LSaveDialog.FileName:= FFileName;
  Result:= LSaveDialog.Execute() and SaveToFile(LSaveDialog.FileName);
  if Result
    then LSaveDialog.InitialDir:= ExtractFileDir(LSaveDialog.FileName);
end;

Часто юзаю директиву "out" вместо "var", чтобы отличать write-only-параметры.
Если можно хоть что-то вернуть из метода - всегда пишу функцию! Чтобы можно было подставлять её вызов в условие для "if", "while", "until" и т.п.

Глобальные переменные использую ТОЛЬКО ТАМ, где без них будет сильно хуже.

Об этом gunSmoker писал. Если условие составное, и его запись достаточно длинная, то условие стоит разбивать на несколько строк, каждая их которых заканчивается обозначениям логической операции.

У меня монитор большой.
Это у меня не очень длинное условие. Когда больше - конечно дроблю построчно.

Далее:

function TCommandQueue.GetEmpty: Boolean;
begin
  Result:= Count = 0;
end;

По-моему мнению, имена методов следует выбирать таким образом, чтобы оно формировало фразу, связанную с действием/результатом метода.

Вверно. Но здесь это метод-геттер для свойства:

  TCommandQueue = class(TList<TEthernetCommand>)
  private
    function GetEmpty: Boolean; // <--- геттер
  public
    procedure InsertForward(AItem: TEthernetCommand);
    property Empty: Boolean read GetEmpty; // <--- свойство
  end;

В любом случае, я свой стиль никому не навязываю. За тобой выбор - можешь перенять частично или писать, как тебе больше нравится.


Админам предлагаю создать раздел типа "кладовка папы карло", где постоянно будут жить и пополняться тематические модули (u*Utils.pas) со вспомогательными функциями/классами внутри. Например:

uRegistryUtils.pas
uWinSockUtils.pas
uXmlUtils.pas
uPrintUtils.pas
uCanvasUtils.pas
uStringUtils.pas
uHtmlUtils.pas

284940.png