Контролен лист за добро програмиране

Original: http://www.cs.uky.edu/~raphael/checklist.html 

Този списък трябва да ви помогне да напишете висококачествени програми.
Рафаел Финкел, 17.08.2005

  • Идентификатори: Уверете се, че всички идентификатори са смислени.
    1. Една писмо идентификатори са почти никога смислено.
    2. Имена като flag и temp рядко са смислени. Вместо flag, помислете за именуване на Булева състоянието го проверява за, като valueFound.
    3. Помислете няколко думи идентификатори, като nameIndex. Дълги идентификатори (в рамките причина) са склонни да бъдат много за четене.
  • Голи литерали: Избягвайте номера, различни от 0 и 1 и струни, различни от “” в програмата си, освен когато определяте константи.
    1. Да не се използва буквално число като масив обвързани.
    2. Да не се използва буквално число като параметър силен, като номер на изчакване или порт.
    3. Да не се използва буквални числа, за да изберете записи в менюто.
    4. Да не се използва буквално число за измерване на размера на низ или някои данни; използва sizeof () и strlen () в C и C ++ и .length () и .size в Java.
    5. Да не се използва буквално низ за името на файла. Вие може изходните буквални струни, все пак.
    6. Да не се използва буквално число на индекс в масив, съдържащ хетерогенни данни.
    7. Не декларира идентификатор с име означаващ буквално, като “тридесет”.
  • Модуларизация: Програма, е изградена от взаимодействащи си компоненти.
    1. Не поставяйте всичките си код в main() рутина.
    2. В действителност, не правят рутинни направи твърде много работа. Ако е по-дълго от около 50 линии, това е може би прекалено дълго.
    3. Ако дублира код няколко пъти, помислете дали една линия ще работи по-добре, или може би подпрограма.
    4. Ако откриете, че са редовете на много дълбоко, най-вероятно не използвате подпрограми, когато трябва.
    5. Не преосмисли библиотечни практики (освен ако не си задача изисква). Погледнете в наръчниците, за да научите за sprintf () и  atoi () , например.
    6. Използвайте заглавни файлове в C и C ++ (заглавни файлове имат имена, завършващи  .h ) да определи всички константи, необходими на множество файлове и да декларират всички подпрограми, изнесени между файлове. Но не се постави тялото на подпрограми в заглавните файлове (с редки изключение на вградените подпрограми).
  • Форматирането: Вашата програма трябва да бъде лесен за четене.
    1. Погледнете  http://geosoft.no/development/javastyle.html  за ясни предложения за форматиране и други проблеми с показването. Тази справка е специално насочена към Java, но той има стойност за други езици, също.
    2. Опитайте се да ограничите всички ваши линии до 80 знака; Много хора гледат код в 80-колона прозорци по исторически причини.
    3. Не използвайте разделите, така и пространства за отстъп, защото не всички текстови редактори лечение разделите като точно 8 места.
    4. Изпълнявайте последователен отстъп модел, който отразява контролна структура на програмата.
    5. Не слагайте много празни редове в програмата си. Един празен ред между подпрограми е достатъчно.
    6. Различни операционни системи да прекратят линии различни начини. Ако преместите между Win32 (което използва\R\Н), Unix (което използва\Н) и MacOS (което използва\R), преформатират файла си да използва последователен метод прекратяване.
    7. Не настройвайте изпълнимия бит (Unix) от вашите изходни файлове.
  • Кодиране: Искате вашата кодиране, за да бъде ясно, за поддържане и ефективно, в този ред. Някои от правилата тук са много специфични; други са по-общи.
    1. Да не се използва поредица от  ако  изявления, които нямат  друго, ако само един може да съвпадат; използвате  друго, ако .
    2. Когато искате да се категоризират въвеждане на текст, не се изброят възможните първите букви.
    3. Използвайте оперативния си персонал вместо умножение за изграждане на модели на битове.
    4. В превключвател изявление, винаги проверявайте за случая по подразбиране. По същия начин, в последователност от ако-тогава друг отчети, използването на крайния друг.
    5. Всички системни функции могат да се провалят. Винаги проверявайте кода на връщане, и да използвате perror () за да съобщите за повредата.
    6. Булеви трябва винаги да използват  булева  тип в Java,  BOOL  в C ++, и 0/1 числа в С не се използва символа т и F, и не използват -1 и 1.
    7. Използвайте примки за инициализиране на структури от данни, ако е възможно.
    8. Използвайте всяка променлива и всяко поле на структура за точно една цел. Не ги претовари, освен ако не е една отлична причина да го направят.
    9. Да не се използва един и същ идентификатор за двата типа, променлива, както и името на файла, дори ако промените капитализация. Това е твърде объркваща.
    10. Ако променяте данни с htonl () или подобна рутина преди преносната мрежа, не се променя данните на мястото си. Изграждане на втората структура на данните.
    11. Опитайте се да не се използва в световен мащаб или нелокални променливи. Декларирам всяка променлива в най-малкия обхват можете. Има законосъобразно използване на нелокални променливи, но се уверете, че наистина имате нужда от тях.
    12. Shell, Perl и Python програми следва да имат свои  #!  линия, както на първия ред на файла; в противен случай, линията е просто коментар.
    13. Опитайте се да избегнете кодиране специални случаи. Често можете да използвате псевдо-данни или други методи на данни за структурата, които ви позволяват да се прибират в специални случаи редовните случаи.
  • Съставители: Нека им помогнем да намерите грешки
    1. Винаги се позове компилатори с всички предупреждения скрипт. За C и C ++, използвайте  -Wall флаг. За Java, използвайте -Xlint: all -deprecation и използвайте PMD програмата, за да получите предложения за по-добро стил. За Python, използвайте  -t-W all.
    2. Всички програми на Perl би трябвало да работи с  -w флаг и трябва да имат употреба строг. Всички Perl CGI-скриптове бин трябва да имат -T флаг, също.
  • В грим помощната програма: Използвайте го, и да я използват добре.
    1. Направете файл винаги трябва да има “чисти” рецепта, която трябва да се премахнат всички файлове, които могат да бъдат възстановени от други рецепти в направете файл, включително обект и изпълними файлове.
    2. Ако вашият проект има множество изходни файлове, на Направете файл трябва да създава обект ( .o ) файлове, ако е необходимо и да ги свържете заедно.
    3. В Направете файл трябва да е написан така, че ако я пускате направи два пъти подред, на втория опит не прави прекомпилиране.
    4. Всяка рецепта трябва да се създаде определен в целта си файла.
    5. Всяка рецепта трябва да използвате всеки файл, посочен в списъка предпоставка.
    6. Научете се да използвате правила за цели като  .co  да се избегнат повторения Направете файлове.
    7. Ако имате само един C или C ++ източник файл, изпълним файл трябва да имат едно и също име (без разширение .c или .cpp ).
    8. Уверете се, че се изброят всички .h файлове като предпоставки, където те са необходими. Помислете за използване  makedepend да генерира списък предпоставка за вас.
  • Документация: Това не е просто само за грейдер. Това ще ви помогне по време на писането на програмата, също!
    1. Добави документация по време на писането на програмата. Винаги можете да го промените като Вашият проект се променя.
    2. Включи външна документация: Как човек компилирате и стартирате програмата, и какво е това означаваше да се направи? Външният документация може да бъде в отделен файл; за малки проекти, може да е коментар във файла-единствен източник.
    3. Включи вътрешна документация: Какво алгоритми и структури от данни, който използвате? Преглед може да бъде в отделен файл, но обикновено вътрешна документация се поставя върху специфичните съчетания, декларациите и стъпките, които го описва.
    4. Проверете целия си програма и документацията за правописни грешки. Това е неучтиво да се превърне в сгрешена работа, и то ангажирам невнимание към детайлите.
    5. Проверете всичките си документация (и изходни съобщения), за граматични грешки.
    6. Програми са много по-разбираеми, ако поставите кратък коментар относно крайните скоби. Например, презрамки затваряне условно може да има коментар, като “ако стойността изглежда добре”. А скоба затваряне на верига може да има коментар, като “за всяка входна линия”. А скоба затваряне на процедура може да има коментар просто именуване на процедурата. А скоба затваряне клас може да има коментар казва “клас” и след това името на класа.

Leave a Reply