Три правила хорошого програмування. Критерії хорошого коду в програмуванні Правила програмування

Перед початком будь-яких операцій перевірте наявність всіх потрібних файлів, папок і змінних. Наприклад, якщо файл не буде знайдений, то ви його зможете створити і позбутися від помилок.
Перевіряйте всі вхідні дані, які передаються за формою. Наприклад, якщо в змінної повинна прийти дата - перевірте чи є які прийшли дані датою. Навіть якщо в формі пропонується вибір цих самих дат. Пам'ятайте, форму завжди можна зберегти локально і поправити її на свій розсуд.
Перевіряйте вхідні дані, щоб вони були тільки в межах діапазону, зазначеного вами. Наприклад, якщо ви поставили обмеження на 1000 символів в повідомленні, а вам написали 2000.
Довжина слів і інші, так як в просту форму можна вести дуже багато символів, з яких вам потрібно буде всього лише 3-4 десятка з початку, то на форму найкраще теж поставити обмеження.
Довжина слів і інше. Якщо ввести слів 20 без пробілу, то на сторінці це буде виглядати непривабливо, а вам це не треба, тому або забороняйте введення таких довгих слів, або розділяйте довгі слова самостійно, або замикайте слова і інше
Ви знаєте, що в поле імені (скрипти: гостьові книги, форуми ...) користувач може ввести що завгодно, в тому числі і ваше ім'я. Але так як в інтернеті не всі чесні, то деякі, які підписалися вашим ім'ям можуть наговорити багато всього нехорошого. Щоб подібного не сталося, створіть список з забороненими іменами і перевіряйте чи не збігається ім'я користувача з ім'ям з цього списку.
Ніколи не показуйте в формі пароля його поточне значення. Пам'ятайте про те, що в цьому випадку пароль може потрапити залишитися в комп'ютері в так званому каталозі тимчасових файлів Інтернету. А якщо це громадський комп'ютер? Тоді наступний хто сяде за нього може легко дізнатися пароль. Крім того форму з паролями обов'язково відправляйте за методом POST.
У вашому скрипті обов'язково повинно бути передбачено модерування. Погодьтеся, набагато простіше і зручніше зайти на сайт, зайти в на сторінку модерування і натиснути на пару кнопок і заповнити пару форм, ніж заходити по FTP на сайт, відкривати потрібну сторінку і колупатися в HTML коді.
Лапки. Замінюйте в одержуваних даних все лапки на ESCAPE - послідовність. Наприклад, лапки [ "] на [\\"]. Дані в форму можна ввести так, що при відображенні може багато чого накоїти з вашої сторінкою. Наприклад, можна вставити скрипт на Java, змінити оформлення. Крім того якщо це у вас форум або гостьова, можна замінювати два пробілу на пробіл, для того щоб кількість прогалин відображалося вірне.
Зберігайте паролі в закодованому вигляді. Адже якщо який-небудь користувач і зуміє скопіювати собі цей файл з паролями, то він пароль не зможе розшифрувати. Якщо користувач забув пароль - міняйте його на абракадабру і відправляйте на Email. При цьому обов'язково видавайте спочатку посилання для підтвердження, щоб ніхто не дізнався пароль.
Завжди замінюйте мітки і роздільники, які ви використовуєте для збереження інформації або відображення, на щось подібне. Інакше є якийсь шанс, що його користувач введе в форму ваш роздільник і на сторінці з'явиться цілий список помилок.
Ніколи не забуваєте ставити error_reporting (0) на початок сторінки, завдяки цьому параметру всі помилки, якщо вони будуть, чи не будуть відображатися на сторінці і зловмисник не зможе дізнатися слабке місце у вашому скрипті.
При підвантаження якогось файлу спочатку переконайтеся в його існуванні, а якщо він і справді існує, то довантажувати його за допомогою функції require, а не include, тому що в 1 випадку якщо буде помилка то файл зовсім буде довантажувати, а у 2 він підвантажиться з помилками.
Перевіряйте звідки користувач прийшов. Тому що користувач може зберегти форму введення у себе на комп'ютері і підправити її, але якщо він спробує відправити через неї дані, то нічого не вийде, так як він його запит прийде не з тієї сторінки, з якої потрібно.

Під час вивчення програмування слід дотримуватися деяких правил, які допоможуть полегшити вашу роботу. Ці правила виконують програмісти всього світу, які використовують всі мови програмування:

коментарі - слід придбати звичку додавати до коду коментарі. Навіть рядки, що здаються ясними в даний момент, можуть стати незрозумілими, якщо ви повернетеся до них через місяць;

імена змінних - використовуйте імена змінних, що відображають їх призначення. Вони доповнять коментарі і допоможуть зрозуміти код, коли ви повернетеся до нього пізніше;

імена функцій - все вищесказане відноситься і до імен функцій. Вони повинні описувати виконувані ними дії;

чим коротше, тим краще - у Flash немає обмеження на довжину функції. Проте, якщо ви напишіть функцію довжиною в 100 рядків, пізніше вам буде непросто її редагувати. Краще розбити функцію на завдання і помістити кожну задачу в окрему функцію;

включайте в код багаторазово використовувані функції - під час програмування не забудьте подумати про те, як можна застосувати ту чи іншу функцію до схожої або аналогічної задачі іншій частині вашої програми. Припустимо, вам необхідна функція, що додає одне очко до рахунку гравця. Постарайтеся використовувати в ній параметр, що дозволяє додавати до рахунку не тільки одне, але і будь-яке інше кількість очок;

намагайтеся обходитися без жорсткого кодування - під жорстким кодуванням мається на увазі включення в ваш код конкретних чисел. Припустимо, для опису правого боку робочого поля в вашому коді використовується значення 550, воно буде жорстко закодовано в програму. Якщо ви вирішите розширити робоче поле до 600 пікселів, вам доведеться змінювати кожне вживання значення 550 в коді. Краще на самому початку задати змінної під назвою screenRightSide значення 550 і використовувати цю змінну протягом всієї програми;

хороша організація - хороший програміст, безсумнівно, повинен вміти організовувати різні елементи програми. Наприклад, функції слід поміщати не в різні кадри, а в один кадр вашого ролика. Крім цього, намагайтеся згрупувати функції відповідно до виконуваних ними завдань.

налагодження

Всім програмістам доводиться налагоджувати створювані ними програми. Неможливо добитися бездоганної роботи програми при її першому запуску. Хороший спеціаліст повинен вміти налагоджувати програму.

Крім використання відладчика ActionScript, налагодження можна проводити різними способами. При пробному відтворенні ролика в вікні Output можуть з'являтися повідомлення про помилки. Іноді цього достатньо, щоб ви зрозуміли, в якому місці коду у вас проблеми 10.

Інформація про програму може також розміщуватися у вікні Output за допомогою команди trace. Вона допоможе вам відстежити певні моменти програми і значення деяких змінних в ці моменти.

Якщо ж ви хочете скористатися програмою налагодження, радимо вам вивчити відповідну інформацію в керівництві по Flash MX. Програма налагодження є простим інструментом, що дозволяє відображати значення змінних під час відтворення Flash-ролика. Однак вона не в змозі творити чудеса; програма налагодження може тільки допомогти вам розібратися у власному проекті.

Останнім часом я бачив мало дійсно хорошого коду, багато посереднього і дуже багато - поганого. (Багато того, що я писав раніше - особливо, коли я тільки починав - відноситься до останніх, на жаль.) Читаючи випадкові статті в інтернеті і професійні книги, я прийшов до висновку, що писати хороший код - легко. Неймовірно важко, але в той же час легко. Насправді, це настільки просто, що зводиться до трьох правил.

Пишіть код для людей, а не машини.
Кожен фрагмент коду повинен виконувати одну задачу.

Дотримуючись їх постійно, ви будете писати хороший код. На будь-якій мові програмування і в будь-який парадигмі. Проблема в тому, що це дуже важко. Всі вони вимагають дисципліни, а для двох останніх в більшості випадків потрібні ще й тривалі роздуми.

Пишіть код для людей, а не машини

Це найважливіше з трьох правил, що лежить в основі двох інших. Пишіть код, який простий для людини; залиште важку роботу комп'ютера. Використовуйте осмислені імена змінних і методів. Не створюйте заплутаних логічних ланцюжків там, де можна застосувати і прості. Не намагайтеся вмістити в одному рядку якомога більше. Дотримуйтесь єдиний стиль написання коду, в якому є осмислені відступи. Якщо ваші файли настільки громіздкі, що їх стає складно прокручувати, розбийте їх на декілька невеликих.

Багато програмістів намагаються писати те, що на їх погляд працює швидше, зменшує розмір програми - словом, "полегшує" роботу комп'ютера. Це чудово, але не забувайте, що набагато важливіше писати код, який буде легко читати і підтримувати іншим людям.

Ваш компілятор (або інтерпретатор) може обробляти абсолютно різні стилі коду. Для нього n і numberOfObjects - це одне і теж. Для людей - немає. Вони будуть довго вчитуватися в код, навіть якщо призначення змінної здається вам очевидним.

Уявіть, що ви зробили для себе маленький скрипт, і через кілька років вам знадобилося трохи змінити його. Що б ви хотіли побачити: добре структурований скрипт, з коментарями і зрозумілим найменуванням, або одну функцію без єдиного коментаря і зі змінними, призначення яких зрозуміти практично неможливо?

Якщо ви робите щось неочевидне, щоб оптимізувати частина коду, опишіть у коментарі, що саме вона робить. Але не забувайте, що в більшості випадків ви не зможете оптимізувати програму краще, ніж компілятор. Реальність така, що він розумніший за вас. Це факт: компілятори поліпшувалися протягом десятиліть важкої роботи професіоналів. Бувають і винятки, але вони лише підтверджують правило.

Пишіть код, зрозумілий людям.

Не повторюйте себе

Я не можу порахувати, скільки разів один і той же фрагмент коду зустрічався мені в різних частинах програми. Якраз сьогодні я працював над великою функцією в застарілому коді і побачив однакові умови в двох різних частинах умовного виразу. Мені довелося витратити час на те, щоб переконатися, що це просто помилка програміста.

Коли ви повторюєте один і той же фрагмент в декількох місцях, вам рано чи пізно доведеться до нього повернуться, щоб виправити будь-яку помилку або додати що-небудь нове. Це ускладнює підтримку коду. Замість того, щоб повторювати себе, помістіть фрагмент в окремий клас або функцію, до якої можна буде звернутися, як тільки вона знадобиться. Якщо ви в різних місцях викликаєте кілька методів в одному і тому ж порядку, оберніть його в окрему функцію.

Подумайте, що буде легше зрозуміти при знайомстві з кодом: фрагмент довжиною в 30 рядків, який звільняє блок пам'яті, або виклик функції clearMapVariableMemory ()?
Можливо, вам знадобиться вивчити фрагмент пізніше, але навіть в цьому випадку працювати з окремою функцією буде легше.

Цей же принцип може бути застосований і до даних. Якщо ви часто використовуєте одні і ті ж змінні, перенесіть їх в окремий клас або тип даних.

Якщо дотримуватися цього правила, все зміни будуть універсальними - вам не доведеться переробляти десятки місць, щоб внести невелику поправку.

Не повторюйте себе.

Кожен фрагмент коду повинен виконувати одну задачу

Останнє правило засноване на двох попередніх: кожен фрагмент вашого коду повинен виконувати тільки одну задачу. Воно вірно на всіх рівнях: для виразів, функцій і методів, класів і об'єктів.

Кілька років тому один розробник показав мені непрацюючий фрагмент коду. Для того, щоб розібратися в ньому, програмісту потрібно декілька годин. У підсумку проблема виявилася в пост-інкрементальних операторах C (в особливих випадках їх поведінка відрізняється від компілятора до компілятору). Згодом, читаючи одну книгу по розробці, я зазначив, що справжня проблема полягає не в операторах, а в тому, що один фрагмент відповідав за виконання безлічі різних завдань.

Наскільки я пам'ятаю, рядок, що містить помилку, була частиною тернарной операції. Та, в свою чергу, виконувала кілька операцій над покажчиками, щоб порахувати умова, і ще кілька, в залежності від результату умовного виразу. Це був хороший приклад написання коду в першу чергу для машини, а не для людини: ніхто, крім автора фрагмента, не зрозуміє, що саме робить рядок, навіть прочитавши її кілька разів. Якби програміст, який написав код, розбив логіку на кілька частин, на вирішення проблеми пішло б куди менше часу.

Не варто витягати, обробляти і змінювати дані в одному і тому ж методі. Словесний опис кожної функції повинно міститися в одне речення. Призначення кожного рядка має бути ясно. Це робить код зрозумілим людям. Ніхто з нас не може зберігати в голові функцію довжиною в кілька тисяч рядків. Немає і істотного підстави створювати такі функції замість кількох невеликих методів, використовуваних разом.

Треба відзначити, що це не так складно: для виконання однієї великої завдання необхідно всього лише розбити її на кілька менших, кожна з яких знаходиться в окремій функції. Важливо стежити за тим, щоб призначення кожної функції залишалося зрозумілим, інакше код стає занадто заплутаним.

Кожен фрагмент вашого коду повинен виконувати одну задачу.

висновок

Написання хорошого коду - це важка праця. Я займаюся програмуванням протягом чотирьох років - не так довго, але цілком достатньо, щоб побачити досить багато проблем, в тому числі і своїх. Мені стало зрозуміло, що ми ускладнюємо розробку, не дотримуючись цих простих правил. Дотримуватися їх правильно - складно: не завжди адже очевидно, де потрібен окремий клас або метод. Це навик. На те, що б стати хорошим програмістом, потрібно багато часу. Але якщо ми не будемо дотримуватися цих правил, написання і підтримка коду стануть ще складніше.

Переклад статті

Кожна програма повинна починатися з коментаря, що містить ім'я і прізвище програміста, призначення програми, номер версії та дату створення.

Кожна підпрограма повинна починатися з коментаря, коротко описує призначення підпрограми. Коментарі повинні описувати що робить код, а не як він це робить. Відстежуючи код, програміст сам побачить, як він працює.

У вихідному коді вельми корисні порожні рядки, що позначають розбивку програми на розділи.

Якщо призначення оператора або групи операторів важко зрозуміти з вихідного коду, то він повинен бути забезпечений коротким коментарем. Однак описувати окремі оператори слід якомога рідше. Зазвичай ефективність таких коментарів невелика. Якщо коментар описує те, що неважко помітити з коду, він навіть ускладнить читання коду. Якщо такий коментар все ж необхідний, розташовуйте його на початку блоку, щоб не розривати структуру програми.

Імена змінних і підпрограм повинні бути інформативними, тобто такими, щоб, дивлячись на них, інший програміст міг здогадатися про призначення змінної або підпрограми. Погано підібране ім'я, дезорієнтуюча читача, навіть гірше, ніж неінформативне ім'я, наприклад X або A. Імена змінних повинні складатися з букв нижнього регістру, окрім букв, з яких починається друге або наступні слова, що входять до ім'я, наприклад taxRate або numberOfCars. Імена підпрограм повинні починатися з літери верхнього регістру.

Імена об'єктів, властивостей і методів повинні починатися з букв верхнього регістру.

Ім'я кожного компонента має починатися з префікса, що складається з трьох букв нижнього регістру і позначає тип компонента. Наприклад, ім'я форми містить префікс frm, Поля введення - edt, Кнопки - btn і т.д. Букви після префікса описують призначення або зміст компонента. Наприклад, поле введення edtLastName містить прізвище.

Для поліпшення читаності вихідного тексту програми рекомендується писати не більше одного оператора в рядку, що викликано особливостями сприйняття тексту людиною. Крім того, це полегшує покрокову налагодження в символьних відладчика.

Не слід побоюватися того, що програма дуже виросте в довжину, так як реальні програми і без того настільки довгі, що кілька «зайвих» сторінок (або навіть десятків сторінок) не змінюють загальну ситуацію. Виграш же в понимаемости з надлишком покриває збільшення довжини.

Два оператора в рядку цілком припустимі, якщо другий підпорядкований першому, причому є єдиним підлеглим. Використання двох і більше операторів в рядку не тільки допустимо, але і бажано, якщо це дозволяє підкреслити якусь систему в локальній послідовності операторів.

4.2. Правила розробки програм

У всіх речових констант цифри повинні бути як зліва, так і праворуч від десяткового дробу, наприклад 0.15, а не.15.

Слід по можливості уникати змішаних арифметичних операцій, які виконуються над операндами різних типів. Використовуйте вбудовані підпрограми перетворення типів.

Для перетворення дійсного значення в рядок і назад використовуйте процедури Str() і Val(), а для цілих значень в мові Object Pascal - функції StrToInt() і IntToStr() відповідно.

Вирази, що складаються з багатьох операторів, повинні містити круглі дужки, що полегшують розуміння цих виразів.

Видаляйте непотрібний код. Особливо це відноситься до операторів усередині циклів, що виконуються багаторазово. Наприклад, немає необхідності присвоювати значення змінним або елементів масиву перед присвоєнням їм значень іншими операторами. Будь-який такий оператор присвоювання зменшує ефективність програми і робить код більш громіздким.

Уникайте використання глобальних змінних. Якщо кілька підпрограм використовують одну і ту ж глобальну змінну, то можуть виникнути серйозні проблеми в процесі налагодження, так як важко буде відстежити, яка підпрограма змінює її значення. Змінні, що використовуються в декількох підпрограма, краще передавати через параметри, так як в цьому випадку їх використання стає більш очевидним.

Років 5-7 тому я сформулювала звід правил, яким керувався при роботі над проектами (в основному автоматизація управління підприємствами), ну і плюс в цьому ж дусі намагався вчити підлеглих (в ролі прожект менеджера). Сьогодні ось натрапив на ці правила, почитав, пустив сльозу :) Згодом погляди змінюються і з деякими правилами я вже не зовсім згоден, що зайвий раз говорить про те, що складати подібні списки - справа невдячна. А ще, коли знаходишся всередині предметної області (нагадаю - автоматизація підприємств), стикаєшся з щоденними помилками проектування, то ці правила цілком розумні, зрозумілі і застосовні на реальних ситуаціях. А з точки зору непрограмістів або програміста з іншої галузі, деякі з правил напевно звучать пафосно, банально або безглуздо. Так що не впевнений, що всі зрозуміють, але все ж опублікую.

Перше правило програміста

Розділяй і володарюй.
(© імовірно Гай Юлій Цезар)

Сенс: розділяй велику задачу на маленькі і вирішуй їх по черзі. Однак пам'ятай про завдання в цілому: все маленькі рішення повинні в кінцевому підсумку вести до вирішення великого завдання.

Друге правило програміста

Краще день втратити, зате потім за п'ять хвилин долетіти.
(© Орел з м / ф «Крила, ноги, хвости»)

Ознака хорошого програміста - автоматизація власної діяльності.
(© ibigdan)

Ніколи немає грошей і часу, щоб зробити все як треба. Але на те, щоб потім переробляти, і час і гроші знаходяться.
(© Закон Хеопса)

Сенс: недостатньо успішно закінчити завдання, потрібно вийти з неї з новим багажем. Створюй не тільки кінцеві рішення, а й методи + інструменти - все це стане в нагоді в цьому і в наступних проектах. Роби це, навіть якщо підтискають терміни, тому що якщо ти не ростеш - ти відстаєш. Замовнику та начальнику на це плювати, тобі немає.

Третє правило програміста

Read The Fucking Manual
(© зневірений сисадмін)

Знання деяких принципів легко компенсує незнання деяких фактів.
(© Гельвецій)

Сенс: ви повинні вміти злітати високо і пірнати глибоко. Вміти побачити задачу в цілому і вміти розібрати її до найдрібніших деталей. Без системного мислення і аналітичного складу розуму в програмуванні робити нічого.

Четверте правило програміста

Не так багато сутностей, як поглядів на них. Сутність - основа рішення, погляд на неї - доробка під конкретну задачу.
(© ibigdan)

Сенс: наприклад «директор» - це не людина, це посада, яку може займати людина (а може ніхто не позичати). І «Іванов Петро Сидорович» - не людина, а прізвище, ім'я та по батькові, тобто атрибути людини. Людина - це тіло, живе або мертве, з купою атрибутів :) Зазвичай до таких нюансів при проектуванні не опускаються, тому більшість автоматизованих систем управління дуже негнучкі.

П'яте правило програміста

Відповідай на питання «що це?» - отримаєш термін. Відповідай на питання «навіщо це?» - отримаєш сенс. Можливо на питання «як краще це зробити?» відповідати вже не доведеться.
(© ibigdan)

Суть програмування в тому, що б розібрати предметну область на дрібні шматки (аналіз) і відтворити її в комп'ютері у вигляді працюючої моделі (синтез).
(© ibigdan)

Сенс: все програмування зводиться до чергування аналізу і синтезу. Причому аналіз може бути математичним, функціональним, об'єктним - будь-яким. І мова синтезу теж значення не має. Важливо тільки розуміння і грамотне виконання цих двох етапів.

Шосте правило програміста

Сенс: якщо сутність з'являється в автоматизованій системі більше одного разу, значить ви серйозно накосячілі при проектуванні. Приклад: «Іванов Петро Сидорович, посада: лікар, місце роботи: урологічне відділення». Потім у нього трапляється інфаркт і опа! - об'єкт номер два: «Іванов Петро Сидорович, пацієнт, кардіологічне відділення». Насправді це один і той же чоловік, але в системі значиться як два різних, не пов'язаних між собою. Причому це типова і елементарна помилка проектування, а є куди більш заплутані. Більшість АСУП складаються з таких помилок більше ніж повністю.

Сьоме правило програміста

Сенс: кілька смислів. Не поспішай радіти знайденому рішенню, можливо воно враховує суті, але не враховує зв'язку. Старі рішення можуть не працювати на нових завданнях іншого масштабу. Взагалі про проблеми масштабування не розкажеш.

Восьме правило програміста

Програмний продукт, що моделює якусь предметну область, фізично не може бути простіше цієї предметної області.
(© ibigdan)

Слідство: універсальний програмний продукт на кілька порядків складніше спеціалізованого, оскільки охоплює групу взаємопов'язаних областей.
(© ibigdan)

Сенс: на жаль, ніхто не виділить вам ресурси на пошук відповіді на «головне питання життя, всесвіту і ваще». Шукайте компроміси між бажаним і можливим.

Дев'яте правило програміста

При автоматизації організаційного управління на основі використання ЕОМ слід пам'ятати, що головною запорукою її успіху є докорінна зміна традиційної технології організаційного управління.
(© В.М.Глушков)

Автоматизація не самоціль, а інструмент оптимізації діяльності підприємства. Якщо автоматизація НЕ оптимізує, то в ній немає ніякої необхідності.
(© ibigdan)

Сенс: немає більшого ідіотизму, ніж автоматизувати паперовий документообіг, створюючи його точну копію в комп'ютері. Деякі програмісти так хочуть зробити «звичний користувачеві» інтерфейс, що малюють на екрані паперові листи, розміщують на них рядки і таблички в тому ж вигляді, в якому вони були на паперових накладних і т.п. З маркетингової точки зору це виправдано, але тільки ось до автоматизації це відношення не має - раніше був хаос на папері, тепер хаос в комп'ютерній мережі. Не потрібно забувати, що документ - не сутність, а «бухгалтерський погляд» на неї, сутність - це товари, перераховані в накладній, ось реальний об'єкт, операції з ним і потрібно автоматизувати. Паперовий документообіг - це всього лише спроба «автоматизації», яку провели за сто років до вас і до появи комп'ютерів, не потрібно її автоматизувати, потрібно її замінити. Це був приклад, таких моментів повно в будь-якій області.