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

Потім знову можна написати так само поганий код, як і раніше, тому що вам просто все одно. Але яка ваша думка?

Я думаю, що програмісти знайдуть інший спосіб додати коментарі ...

string aComment = "This is a kludge.";

Я не думаю, що це так просто:

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

Припустимо, ви ідеальний програміст (чого ви не є, але давайте просто припустимо) ...

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

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

Немає заміни на добру практику розвитку.

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

У той час як видалення коментарів може змусити деякі розробник до коду записи , що краще при самостійній документації, є ще розробники, що там записи погано документована коду (тобто імена змінні a, b, cі т.д.) , і це ті звички , які люди повинні бути навчені з з. У таких випадках видалення коментарів не вплине на цих розробників і може перешкодити зусиллям інших розробників пояснити складні фрагменти коду.

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

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

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

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

Дивись також...

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

Я уникаю коментувати код, і він працює.

Я уникаю всіх кодових (вбудованих або потокових) коментарів на користь docblock + змістовного varables + спартанського програмування , і це працює.

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

Я думаю, що може замінити коментарі: стандартизована мова докблоку / синтаксис / ідіома, щось на зразок анотацій на Java.

Це не тільки не вплине на якість - як це зауважили інші, це насправді буде прикро.

Я впевнений, що час від часу щось із нас робило щось подібне:

foreach ( myObject obj in SomeList )
 {
    Debug.Writeline( obj.Name );
//  for some reason this isn't working
//  obj.SetArielPotency( setting );
//  obj.DoSomeProcess();       
 }

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

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

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

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

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

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

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

Рент: Іноді я думаю, що більш дозвільні мови дозволяють більшій кількості людей навчитися правильно кодувати, а не зворотному (тобто єдиний в односторонній спосіб Java і проклятий ти, якщо ти хочеш вважати функції як першокласні об'єкти).

Я здогадаюсь: напевно, ні. Чому? Тому що вам доведеться кодувати "чому" як формалізм у мові і тому, що "чому", чи кодовано мовою чи мовою коментування, програмісти все одно не використовуються.

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

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

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

Я завжди думав, що може бути приємно мати односкладний коментар, щоб, якщо ви встановили префікс слова із символом (скажімо, двокрапка), це слово було б проігноровано. Таким чином, ви можете сказати, що це лише одна однослівна зауваження всередині s-виразу. Наприклад, ви можете перетворити це:

(if (= x y)
    x
    y)

... до цього:

(if (= x y)
    :then x
    :else y)

Якщо вам абсолютно потрібно, ви можете зв'язати кілька односкладних коментарів, щоб сформувати вбудований коментар:

(if x :Remember, :x :could :be :nil!
    ...)

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

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

Причини, чому це гарна ідея: - Ні

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

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