Як виглядає код хорошого програміста? [зачинено]

Я програміст-любитель (я почав з VBA, щоб швидше робити Excel) і працюю з VB.NET / C # .NET і намагаюся вивчити ADO.NET.

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

• Вони краще розуміють усі об'єкти / класи / методи даної мови?
• Їхні програми ефективніші?
• Дизайн їх програм набагато кращий з точки зору кращої документації, гарного вибору назв функцій тощо?

Іншими словами, якби я дивився на код професійного програміста, що перше, що я помітив би щодо їх коду відносно мого? Наприклад, я читаю такі книги, як "Професійний ASP.NET" від Wrox press. Чи є приклади коду в цій книзі "світовим класом"? Це вершина? Чи подивився б хтось із програмістів-програмістів на цей код і подумав би, що це хороший код?

Список нижче не є вичерпним, але це те, про що я думав, розглядаючи ваше запитання.

• Хороший код добре організований. Дані та операції в класах збігаються. Немає сторонніх залежностей між класами. Це не схоже на "спагетті".

• Хороші коментарі до коду пояснюють, чому все робиться не те, що робиться. Сам код пояснює, що зроблено. Потреба в коментарях повинна бути мінімальною.

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

• Хороший код добре перевірений. Тести служать виконуваною специфікацією коду та прикладами його використання.

• Хороший код - це не "розумно". Він робить речі простими, очевидними способами.

• Хороший код розроблений в невеликих, легко читаються одиницях обчислення. Ці одиниці повторно використовуються в коді.

Я ще не читав, але книга, яку я планую прочитати на цю тему, - « Чистий код » Роберта К. Мартіна.

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

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

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

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

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

Цитуючи Фаулера, підсумовуючи читабельність:

Будь-який дурень може написати код, зрозумілий комп’ютеру.
Хороші програмісти пишуть код, який люди можуть зрозуміти.

- сказав ну.

Особисто мені доведеться процитувати "Дзен Пітона" Тіма Пітерса. Він повідомляє програмістам Python, як повинен виглядати їх код, але я вважаю, що це стосується в основному всього коду.

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

Код - це поезія.

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

Наступні наслідки:

Зчитувач буде вами в момент часу n з дати створення коду. Виграш від написання коду для читача є монотонно зростаючою функцією n. Читач, який вперше переглядає ваш код, позначається n == нескінченністю.

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

Другий наслідок:

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

Третій наслідок:

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

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

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

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

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

Прочитайте книгу Code Complete. Це пояснює багато ідей про те, як структурувати код, і причини цього. Її читання повинно скоротити ваш час, щоб набути досвіду, необхідного для відмінності хорошого від поганого.

http://www.amazon.com/Code-Complete-Practical-Handbook-Construction/dp/0735619670/ref=pd_bbs_sr_1?ie=UTF8&s=books&qid=1229267173&sr=8-1

Програмуючи вже майже 10 років і працюючи з іншими, без упереджень можу сказати, що немає різниці між хорошим програмістом і середнім кодом програмістів

Усі програмісти на компетентному рівні:

• Коментар правильно
• Структура Ефективно
• Документуйте чисто

Одного разу я почув, як співробітник сказав: " Я завжди був дуже логічним і раціональним. Я думаю, саме тому мені подобається розвиватися "

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

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

Лаконічно кажучи, хороший код програміста можна прочитати і зрозуміти.

На мою думку, хороший код програміста є мовно-агностичним ; добре написаний код можна прочитати і зрозуміти за короткий проміжок часу з мінімальним продумуванням, незалежно від використовуваної мови програмування. Незалежно від того, чи є код на Java, Python, C ++ або Haskell, добре написаний код зрозумілий людям, які навіть не програмують на цій конкретній мові.

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

Наприклад, днями я розглядав код для TinyMCE, щоб відповісти на одне з питань щодо Stack Overflow. Він написаний на JavaScript, мовою, якою я майже не користувався. Тим не менше, завдяки стилю кодування та коментарям, які включені, а також структуруванню самого коду, це було досить зрозуміло, і я зміг перейти по коду за кілька хвилин.

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

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

• Легко читається
• легко писати
• простий в обслуговуванні

все інше - філігрань

Хороший код повинен бути зрозумілим.
Це слід добре прокоментувати.
Складні частини слід ще краще коментувати.

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

Замість цього повторюйте чудові пропозиції всіх інших, я натомість пропоную вам прочитати книгу Code Complete Стіва Макконнелла

По суті, це книга, наповнена найкращими практиками програмування як щодо функціональності, так і для стилю.

[Суто суб’єктивна відповідь]
Для мене хороший код - це вид мистецтва, як і картина. Я міг би піти далі і сказати, що насправді це малюнок, який включає символи, кольори, "форму" або "структуру" коду, і все це є таким читабельним / продуктивним. Поєднання читабельності, структури (тобто стовпців, відступу, навіть назв змінних однакової довжини!), Кольору (імена класів, імена змінних, коментарі тощо) - все це робить те, що мені подобається бачити, як "красиву" картинку, яка може змусити мене або дуже пишатися, або дуже ненавидіти свій власний код.

(Як вже було сказано раніше, дуже суб'єктивна відповідь. Вибачте за мою англійську.)

Я підтримую рекомендацію "Чистого кодексу" Боба Мартіна.

"Прекрасний кодекс" був високо оцінений пару років тому.

Будь-яку книгу Макконелла варто прочитати.

Можливо, "Прагматичний програміст" також буде корисним.

%

Просто хотів додати свої 2 центи ... коментарі до вашого коду - і сам ваш код, загалом - повинен сказати, що робить ваш код, тепер як він це робить. Після того, як у вас є поняття «клієнтський» код, тобто код, який викликає інший код (найпростішим прикладом є код, який викликає метод), ви завжди повинні найбільше турбуватися про те, щоб зробити ваш код зрозумілим з точки зору «клієнта». У міру зростання вашого коду ви побачите, що це ... ну, добре.

Багато інших речей про хороший код стосуються розумових стрибків, які ви зробите (безумовно, якщо ви звернете увагу) ... 99% з них пов’язані з виконанням трохи більше роботи зараз, щоб позбавити вас тонни робота пізніше та багаторазове використання. А також правильно робити речі: я майже завжди хочу бігти в інший бік, а не використовувати регулярні вирази, але кожного разу, коли я потрапляю в них, я розумію, чому всі використовують їх на кожній мові, на якій я працюю (вони невпевнені, але робота і, мабуть, не може бути кращим).

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

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

На це досить добре дається відповідь у книзі Фаулера "Рефакторинг". Це відсутність усіх "запахів", які він описує у всій книзі.

Я не бачив "Професійного ASP.NET", але я був би здивований, якщо це краще, ніж ОК. Див. Це запитання щодо деяких книг із справді хорошим кодом. (Звичайно, це різниться, але прийняту відповідь важко перемогти).

Здається, це (повинно бути) FAQ. Є стаття ACM про красивих коді в останній час . Здається, тут робиться великий акцент на легко читаному / зрозумілому. Я б кваліфікував це як "легкий для читання / розуміння експертами доменів". Дійсно хороші програмісти, як правило, використовують найкращі алгоритми (замість наївних, легких для розуміння алгоритмів O (n ^ 2)) для будь-яких проблем, за якими може бути важко слідувати, якщо ви не знайомі з алгоритмом, навіть якщо хороший програміст дає посилання на алгоритм.

Ніхто не ідеальний, включаючи хороших програмістів, але їх код прагне :

1. Коректність та ефективність із перевіреними алгоритмами (замість наївних та прихильних хаків)
2. Чіткість (коментар щодо наміру з посиланням на нетривіальні алгоритми)
3. Повнота охоплення основ (конвенція про кодування, встановлення версій, документація, модульні тести тощо)
4. Стислість (СУХА)
5. Надійність (стійкість до довільного введення та порушення запитів на зміну)

я рекомендую "чистий код" дядька Бобу. але ви можете поглянути на http://www.amazon.com/Implementation-Patterns-Addison-Wesley-Signature-Kent/dp/0321413091, оскільки, на мою думку, це стосується вашого конкретного питання трохи краще. хороший код повинен зіскочити зі сторінки та повідомити вам, що він робить / як це працює.

Джефф Етвуд написав приємну статтю про те, як кодери є першим посиланням друкарки: http://www.codinghorror.com/blog/archives/001188.html

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

Структура

Коментарі

Регіони

Я є програмним інженером, що означає, що під час навчання я стикався з багатьма різними мовами, але моє програмування завжди "відчувало" те саме, як і мої роботи на fekberg.wordpress.com, я маю "особливий" спосіб набору тексту.

Зараз програмуючи різні програми та на різних мовах, таких як Java, C #, Assembler, C ++, C, я дійшов до "стандарту" написання, який мені подобається.

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

Це дуже важливо, я завжди бачу свій код, що я роблю, як "бути частиною API", коли створює структуру API, а елегантність ДУЖЕ важлива.

Подумайте про це. Також прочитайте мою статтю, в Communication issues when adapting outsourcingякій грубо пояснюється, наскільки поганий код може конфліктувати, Enterpret, як вам подобається: http://fekberg.wordpress.com/2008/12/14/communication-issues-when-adapting-outsourcing/

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

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

Хороший код - це те, звідки ви знаєте, що робить метод з назви. Поганий код - це місце, де вам потрібно розробити, що робить код, щоб зрозуміти назву.

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

Хороший код має речі, названі таким чином, щоб зробити тривіальні коментарі непотрібними.

Хороший код, як правило, короткий.

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

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

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

Коли програміст має такий спосіб мислення, всі інші речі прекрасно стають на свої місця.

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

(Я використовую "він" нижче, тому що це людина, якою я прагну бути, іноді з успіхом).

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

Таким чином, його код повинен:

1. Робота (не має значення, наскільки швидко код потрапляє до неправильної відповіді. Часткового кредиту в реальному світі немає).
2. Поясніть, як він знає, що цей код працює. Це поєднання документації (javadoc - це мій інструмент вибору), обробки винятків та тестового коду. У цілком реальному сенсі, я вважаю, що рядок за рядком тестовий код є ціннішим за функціональний код, якщо ні з якої іншої причини, ніж це пояснює "цей код працює, ось як його слід використовувати, і саме тому я повинен отримати оплачується ".
3. Будьте підтримані. Мертвий код - це кошмар. Обслуговування застарілого коду є клопотом, але це потрібно зробити (і пам’ятайте, що це „застарілий“ момент, коли він залишає ваш стіл).

З іншого боку, я вважаю, що хороший програміст ніколи не повинен робити такі речі:

1. Одержимість форматуванням. Існує безліч середовищ IDE, редакторів та симпатичних принтерів, які можуть відформатувати код саме за тими стандартними або особистими уподобаннями, які, на вашу думку, доречні. Я використовую Netbeans, я налаштовую параметри формату один раз і час від часу натискаю alt-shift-F. Вирішіть, як ви хочете виглядати код, налаштуйте своє середовище і нехай інструмент виконує бурчання.
2. Одержимість умовами імен за рахунок людського спілкування. Якщо конвенція про іменування веде вас вниз по шляху іменування ваших класів "IElephantProviderSupportAbstractManagerSupport", а не "Zookeeper", змініть стандарт, перш ніж ускладнювати для наступної людини.
3. Забудьте, що він працює у команді з реальними людьми.
4. Забудьте, що основне джерело помилок кодування зараз сидить за його клавіатурою. Якщо є помилка або помилка, він повинен спочатку поглянути на себе.
5. Забудьте, що те, що кружляє, приходить навколо. Будь-яка робота, яку він робить зараз, щоб зробити свій код більш доступним для майбутніх читачів, майже напевно принесе йому безпосередню користь (адже хто стане першою людиною, яку попросять переглянути його код? Він є).

1. Це працює
2. У ньому є модульні тести, які доводять, що це працює

Решта - ожеледь ...

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

Як не дивно, чим кращий програміст, тим менш необхідний він стає, тому що створений код краще підтримується будь-ким (як зазначено за загальною згодою Ерана Гальперіна).

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

У мене є хороший приклад:

Прочитайте вихідний код GWT (google web takeit), ви побачите, що кожен дурень це розуміє (деякі англійські книги важче читати, ніж цей код).