Грамотне програмування, хороша / погана методологія дизайну


10

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

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

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

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

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


2
Зерот, я створив тег грамотного програмування і додав резюме на основі статті у Вікіпедії. Будь ласка, допоможіть розширити вікі тегів із відповідною інформацією.
янніс

@YannisRizos Я додам його сюди, у мене немає привілеїв редагування.
нуль

1
Ну, я ні :) Я додав деякі ресурси (стаття у Вікіпедії та посилання у вашому запитанні), вони з’являться, коли редагування буде перевірено та прийнято (?!). Це інтригуючий підхід, і оскільки ви вже вивчаєте його, повертайтеся та вдосконалюйте вікі тегів кожного разу, коли ви знайдете щось, що, на вашу думку, варто згадати там.
янніс

1
Я б порекомендував автору сайту Literate Programming відвідати сайт UX stackexchange - кольори справді погані для читання.
Денні Варод

1
FYI, literate-programmingна StackOverflow також є тег. Там більше вмісту, хоча все ще не так багато.
Росс Паттерсон

Відповіді:


9

Це призведе до автоматичного введення коду замість окремої компіляції функцій та подальшої вимоги кроку оптимізації міжпроцедурної компіляції для отримання еквівалентної швидкості

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

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

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

Існують деякі аргументи, проти яких усе означає, що "програмування мовою вищого рівня підривається шляхом налаштування отриманого коду". Правильно. Таким же чином, що програмування в C ++ підривається шляхом підстроювання .oфайлу, який виробляється. Це правда, але не має значення.

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

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

Багато чого сьогодні не має значення. Інструменти грамотного програмування можуть бути досить простими, якщо вони зосереджені на сучасних об'єктно-орієнтованих (або функціональних) мовах програмування. Необхідність у складних обхідних шляхах менше обмежена через обмеження C (або Pascal або Assembler).

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

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

Є дуже велика кількість програмістів, які виявляються лише незначно успішними, і то лише випадково. (У Stack Overflow є досить поганих запитань, які вказують на те, що багато програмістів намагаються навіть зрозуміти основи.) Для програмістів, які задають в основному невідповідні запитання щодо переповнення стека, ми знаємо, що вони насправді не можуть зробити гарну роботу грамотного програмування, тому що вони можуть Я не роблю добре програмування.


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

3

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

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

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


1

Хоча я досить нова в самій концепції літературного програмування (і тому, ймовірно, я цілком пропускаю човен), здається, дуже сильно відповідати концепції DSL .

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

Як на мене, ця сама ідея або, принаймні, її основна основа, однакова або принаймні тісно пов'язана з грамотним програмуванням.

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

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

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

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


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

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

Наприклад, такі рядки коду програмування , а не тільки псевдо-пропозиції:

drink tea with sugar and milk
move left by 30.centimeters
sendFrom "Guillaume" to "Jochen"
send from: "Jochen" to "Lidia"
Email.from "Lidia" to "Guillaume" withBody "how are you?"
contact.name "Guillaume" age 33
move left by 30.centimeters
sell 100.shares of MSFT
take 2.pills of chloroquinine in 6.hours
blend red, green of acrylic
artist.paint "wall" with "Red", "Green", and: "Blue" at 3.pm
wait 2.seconds and execute { assert true }
concat arr[0] with arr[1] and arr[2]
developped with: "Groovy" version "1.8-beta-2"

Примітка: Зразок коду походить з блогу Гійом Лафордж

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

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

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

Для отримання додаткових прикладів цього дії (не в певному порядку):


2
Цікава точка зору. З моєї точки зору, це зовсім не дуже добре поєднується з DSL. Оскільки грамотне програмування є деякою мовою, що не належить до DSL. І інструменти теж не дуже схожі на DSL. Вони не орієнтовані на проблемну область. Чи можете ви надати приклад того, як ви вважаєте, що грамотне програмування схоже на DSL? Посилання або посилання на приклад можуть допомогти уточнити вашу відповідь.
С.Лотт

Одним із прикладів цього є командні ланцюги в Groovy 1.8, які дозволяють "програмувати" такі речі, як turn left then rightабо paint wall with red, green and yellow: docs.codehaus.org/display/GROOVY/…
cdeszaq

@ S.Lott - Я погоджуюся, що між DSL та грамотним програмуванням, безумовно, є різниця, але я думаю, що DSL можуть бути інструментом для досягнення справжнього грамотного програмування, де ви можете вводити природну мову і вказувати потрібний алгоритм. Для мене змішання природної мови та коду - це уродлива форма грамотності.
cdeszaq

"Ви можете ввести природну мову та запропонувати їй виразити потрібний алгоритм", в кращому випадку навряд чи. Є передумови, обгрунтування, доказ коректності, твердження складності (великі- O ) та безліч неалоритмічної допоміжної документації, яка не є частиною схеми DSL. Я не впевнений, що я згоден з паралеллю тепер, коли ви це уточнили.
С.Лотт

1
"пояснення логіки програми". Не сама логіка. Але пояснення. Логіка рідко сама собою пояснює. Він ніколи не містить доказ правильності (що важко, а іноді і неможливо). Він рідко містить обгрунтування складності big-O. І це рідко пояснює альтернативи, які є або низькою продуктивністю, або більшою кількістю пам'яті. Отже, я б припустив, що DSL не відповідає "поясненню".
S.Lott

-2

Я думаю, що це помилка, думаючи, що LP - це якась DSL. Тому що LP - це журнал (із схемами, схемами, фрагментами псевдокоду, тобто шматками) розробленої програми, це архітектура тощо ... Це абсолютно аналог паперового ноутбука - багато розробників використовують їх, але після закінчення програми - викиньте свої «зошити, папери ...

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

Сьогодні багато програмістів пишуть код, а іноді вони додають коментарі! Програма Byt - це не лише код - це думки, ідеї, фантазія, концепції, і коли новий розробник успадковує чужорідний код - він часто перебирає всі ідеї та концепції, робить різні "лазівки" та "backdoors", сподіваюся, ви мене зрозуміли :)

Отже, головна вимога до LP (як інструменту!) - занадто дозволити все це за допомогою простого, легкого для читання синтаксису. Я спробував багато інструментів LP, але сьогодні я розробляю власну - NanoLP ( http://code.google.com/p/nano-lp/ ), яка спрямована на задоволення цього попиту.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.