Чому грамотне програмування не є основним? [зачинено]

Грамотне програмування має хороші ідеали. Чому ви вважаєте, що це не мейнстрім? Це тому, що вона не змогла доставити?

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

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

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

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

Це відштовхує людей від чогось, наприклад, cweb / noweb, тому що, використовуючи їх, вам потрібно буде вивчити TeX та синтаксис, характерний для програми, на вершині мови програмування, яку ви використовуєте для проекту. Це можна сприймати як велику марну трати часу, особливо якщо їм не потрібна будь-яка математична набір, яка в першу чергу настільки велика нічия для TeX. (І для багатьох програмістів додатків вони їм справді не знадобляться.) Натомість вони віддають перевагу щось на зразок коментарів XML Visual Studio, тому що це вже популярне та налагоджене.

Місця, в яких я бачив грамотне програмування, знаходяться в науково-статистичних обчисленнях, де більшість програмістів проходять значну підготовку (також доктора наук) з математики, CS або статистики, і тому вже знайомі з LaTeX. Документація, яку вони пишуть, швидше включає багато складних формул, які найкраще записуються в TeX, і вони, швидше за все, програмують в Р. Частка R програмістів, які знають про SWeave, безумовно, набагато вища, ніж, скажімо, частка програмістів на C, які знають про cweb.

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

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

Для тих, кому пощастило не спробувати Standard Pascal, ось деякі основні моменти.

• Щоб полегшити наявність однокласного компілятора, мовна специфікація говорила, що всі декларації повинні надходити в певному порядку. На сторінці вікіпедії: "Кожна процедура або функція може мати власні декларації готових міток, констант, типів, змінних та інших процедур і функцій, які повинні бути в тому порядку". Це означало, що ви не можете згрупувати свої речі логічно разом у вихідному файлі.
• Поводження з струнами було більш стомлюючим, ніж у звичайному С.
• Ідентифікатори не могли мати довільну довжину.
• Ще багато речей, яких я вже не пам'ятаю.

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

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

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

Отже, що залишилося? Можливість генерування набірної форми документації з вихідного коду та ТОГО існує сьогодні.

Подумайте лише, що JavaDoc - API виконання Java - це, мабуть, найбільший фрагмент Літературного програмування, доступного сьогодні (за винятком того, що код насправді не представлений, але це МОЖЕ було, якби Java була відкрита з самого початку). Дивіться, наприклад, презентацію рамки колекцій на http://download.oracle.com/javase/6/docs/api/java/util/Collection.html

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

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

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

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

Кодери пишуть код не англійською мовою.

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

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

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

В основному тому, що люди ДУЖЕ СТУПІДНІ. Очевидне свідчення цього - це нескінченний потік здогадів і непорозумінь, висловлених молодими людьми про природу цієї простої техніки.

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

Однак LP просто: (1) написання програм у суміші кодів та фраз на (= будь-якій) людській мові, де останні розшифровуються для інших фрагментів коду та / або включених фраз. Це саме те, що роблять автори численних підручників з програмування .. і (2) це простий препроцесор, який розширює ті словосполучення в людині (які стали ніби іменами включених підпрограм), щоб розгадати результат у ЗАМОВЛЕННІ, ПОТРІБНОГО КОМПІЛЕР (або перекладач). В іншому випадку можна розширити написаний текст за допомогою іншої невеликої утиліти, щоб включити символи форматування, щоб перетворити "грамотне джерело" в хороший добре відформатований текст, що читається.

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

В основному основна ідея програмування "в псевдокоді", написаної людською мовою, а потім розширення її за допомогою простої утиліти препроцесора ДОПОМОГА УПРАВЛІННЯ УВАГА (обмежена, основна складність для будь-якої тривалої програми), майже як складання коду або поділ потоку вашої програми. у функції / підпрограми, необхідні для того, щоб ви не втрачали себе в деталях, але зовсім непотрібні для виконання машини.

Є 2 аспекти грамотного програмування , що я б бажання були включені в основне русло програмування - вбудовані зображення (наприклад, проектування діаграми) і покажчики на попередні і альтернативні спроби (наприклад, «Причина це так, тому що я спробував цей інший шлях і це не спрацювало, тому що ... "). Обидва ці аспекти можна обробляти за допомогою коментарів doc та URI.

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

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

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

На закінчення: Мій код Java самий грамотний, як це хоче кожен «грамотний» програмування.

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

Для мене, всупереч назві, "грамотне програмування" - це зовсім не документація. У мене немає більшої документації, ніж раніше. Це про те, щоб мати структуру, яка допомагає мені не загубитися . Я клянусь цим особливо під час управління файлами JSP-файлів behemoth (і що, незважаючи на те, що Лев спочатку був призначений в основному для Python, і він не підтримує мову JSP - я повинен розділити файл на дерево Лео вручну!).

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

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

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