Нещодавно я переключався між кількома проектами та середовищами розробки. Очікування стилю кодування у кожного різні.
Тепер моє запитання - це три частини, перша, з цікавості:
Відповіді:
№1. # Як ви визначили та знайшли свій стиль кодування?
Через зразки коду спочатку в книгах, потім у текстах та статтях MSDN, потім в блогах та інших веб-сайтах.
№2. Як ви продовжуєте її збільшувати та вдосконалювати?
Я тримаю очей відкритим для всіх пропозицій людей. Я пробую їх, якщо вони працюють на мене, вони прилипають. Я також час від часу експериментую, що, здається, покращує речі, залишається у мене.
№3. Як ви її підтримуєте? (З розумових записок, зберігання документа, використання такого інструменту, як StyleCop тощо)
Я наче запам'ятовую свій стиль і автоматично застосовую його скрізь.
Примітка 1. Утримувати очі відкритими і вуха гострими вкрай важливо, щоб залишатися в струмі. Роки тому я дізнався від інших, що позначення Угорщини було обов'язковим, тому я дотримувався цього. Коли громада зрозуміла, що це не так вже й велико, я змінився з усіма.
Примітка 2. Часто не так важливо, які конкретні елементи стилю ви приймаєте, а скоріше, щоб ви дотримувались стилю у своїх кодах. Те саме стосується команди. Виберіть якийсь стиль, але тоді дотримуйтесь його.
Примітка 3. Стилі кодування для різних мов можуть відрізнятися. C ++ заслуговує одного стилю, Java іншого. HTML і CSS за своїми характеристиками знову вимагають іншого стилю.
Примітка 4. Який би стиль ви не вибрали, розумійте та приймайте, що він не працюватиме на 100%. Іноді у вас є якийсь код, який вимагає іншого стилю просто на місці, або розділений багаторядковий, різний вирівнювання, або будь-який інший, щоб зберегти цю детальну частину коду легше для читання. Не натискайте свій стиль скрізь, зосередьтеся на читанні коду. Якщо це очевидно, стиль не працює в цьому конкретному місці, зробіть виняток.
Примітка 5. Не слід дотримуватися стилю коду до релігії. Інструменти, що застосовують стиль коду, хороші, але іноді можуть звести з розуму. Я, наприклад, відключив автоматичне форматування коду Visual Studio, тому що це наштовхнуло мене на гайки. Якщо інструмент стає перешкодою, просто додайте виняток і не хвилюйтеся, що ваш код не відповідає 100%. Це не так важливо насправді, і досконалості, якої не можна досягти, все одно.
Я не думаю, що був час, коли я сказав: "Добре, це буде мій стиль". Зосередьтеся на конкретному середовищі чи мові. Ваш стиль повинен відображати те, як ви стикаєтеся з певною проблемою.
Я працював у команді із закритою вихідною грою, яку я любив, а провідний розробник мене наставляв, і допоміг мені покращити свої навички після того, як я попросив його також.
Він запропонував, і я прийняв стиль кодування Zend Framework (http://framework.zend.com/manual/en/coding-standard.html)
Я прийняв характеристики різних стилів - включаючи стилі, відображені на MSDN. Потім я встановлюю шаблони в VS, які надають мої #region/#endregionблоки та все інше, що є кращим.
Я продовжую вивчати інші стилі, з якими стикаюсь через дослідження та читання. Якщо я думаю, що є щось, що виділяється і могло б покращити мій стиль у читанні, технічному обслуговуванні чи організації, я спробую це випробувати. Якщо нове коригування стилю буде в порядку, я оновлю шаблони в VS або буду робити міркування.
Коли я кодую один, я прагну до стислості; Спартанське програмування може бути повним, божевільне божевілля ... Але це, мабуть, найближче знайоме моє віросповідання.
Кодуючи інші, особливо кодування технічного обслуговування, я прагну бути хамелеоном - мої зміни повинні покращити те, що вони змінюють, не дивлячись поза місцем.
Як ви визначили та знайшли свій стиль кодування?
Сфокусувавшись на простоті та читанні (читабельність! == зрозумілість, див. Спартанське програмування )
Як ви продовжуєте її збільшувати та вдосконалювати?
Переглядаючи чужий та власний код (і навіть самі стандарти кодування).
Як ви її підтримуєте? (З розумових записок, зберігання документа, використання такого інструменту, як StyleCop тощо)
Я використовую dokuwiki , вітер для налаштування (без бази даних), ієрархічну структуру, гранульований контроль (ACL поза коробкою), дуже приємно виглядає, і добре, його wiki, тому кожен може зробити свій внесок. Також внески / зміни завжди знаходяться на консенсусі та виправдані, засновані на простоті та читанні.
Це якась дивна відповідь, але мені потрібно було дуже багато часу, щоб фактично підібрати програмування. Я багато часу працював у «мистецтві», перш ніж вважати себе програмістом.
Під час кодування я схильний думати в таких одиницях, як написання - абзаци, фрази і т. Д. Через це я розповсюджую код на більше рядків, намагаючись зробити його читабельним, як розповідь / есе / тощо. Мене дуже дратує, коли розробники намагаються якомога більше піднятися на одну лінію чи на невеликий простір, тому що це нічого не робить, крім того, щоб письменник почував себе розумним і дратував будь-яких майбутніх читачів.
Якщо мені потрібно зробити щось дивне заради ефективності, я прокоментую це, щоб пояснити, чому це так.
Я, мабуть, не отримаю жодної інформації щодо цього, але, можливо, це все одно спричинить дискусію.
Що стосується технічної сторони, як розміщення дужок і подібних, я тримаю їх у вирівнюванні, оскільки результат підвищує читабельність.
1. How did you define and find your coding style?
Я хочу прийняти вже розроблений посібник зі стилів, який значною мірою розвинений і широко прийнятий або популяризований великою компанією / проектом.
Я роблю це з численних причин, але головним чином через те, що такі посібники щодо стилів можуть бути негайно прийняті розробниками. Посібник зі стилів вартий лише стільки, скільки розробники готові дотримуватися його.
Прикладами таких є PEP Пайтона 8 , стиль керівництва Android для Java , JQuery основний стиль керівництва або стиль керівництва Python від Google .
2. How do you keep augmenting and improving it?
Найбільший аргумент для таких стильових посібників полягає в тому, що вони тут не були винайдені і не придумані мною. Для розробників знадобилися десятки розробників, страхітливі рядки коду та більше часу, ніж коли-небудь ваша компанія / команда будуть готові інвестувати в розробку та підтримку керівництва зі стилем.
Щодо вдосконалень, то ніколи не було посібника зі стилів, який би відповідав на все, що вам може знадобитися. Але в більшості випадків вдосконалення, які я бачив, як їх просували вперед, були просто більш детальною версією того, що керівництво стилем вже викладене підходом до написання коду.
У таких випадках, коли ви зіткнетеся з блоком wierdness, вам слід вставити його в суть або в інший відповідний інструмент спільного використання фрагментів коду з підтримкою кольорового синтаксису і десь обговорити його з іншими розробниками. Чудова річ у тому, що в таких випадках вас цікавить не те, що робить код, а лише те, як цей код з'являється, тож ви можете вийняти цей блок із контексту та обговорити, як слід вдосконалювати його, порівнюючи його з тим, що вже вказано в посібник зі стилю як головна відправна точка для дискусій.
3. How do you maintain it?
Що ж, чудова річ, що у вас вже будуть наявні документи, які публічно підтримуються в Інтернеті.
Що стосується форматування коду, ви також можете пройти додаткову милю та забезпечити свою команду конфігураціями форматів для їх улюбленого редактора, який повинен витягнути грубість та здогадки щодо збереження зовнішнього вигляду підказки. Насправді я б не назвав це зайвою милею, але невід'ємною частиною розвитку - немає нічого гіршого, що робити розбіжність, де 90% змін коду було чиєюсь реєстрацією правильного форматованого / стильового коду, тому що хтось забув прибирати, перш ніж вони скористалися величезною новою функцією.
Якщо ви є частиною команди, завжди слід доповнити стандарт команди. Можна багато сказати, щоб використовувати загальний макет, а не свій особистий. Це полегшує ваш код легше читати та розуміти іншими, що важливо.