У який момент стислість вже не є чеснотою?

Нещодавнє виправлення помилок вимагало від мене перегляду коду, написаного іншими членами команди, де я знайшов це (це C #):

return (decimal)CostIn > 0 && CostOut > 0 ? (((decimal)CostOut - (decimal)CostIn) / (decimal)CostOut) * 100 : 0;

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

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

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

_{Причиною кастингу є Entity Framework. DB повинен зберігати їх як нульові типи. Десяткові? не еквівалентно десятковому знаку в C # і його потрібно надати.}

Щоб відповісти на ваше запитання про існуючі дослідження

Але чи було написано чи досліджено щось, щоб визнати точку, коли прагнення до короткості коду перестає бути корисним і стає бар'єром для розуміння?

Так, у цій галузі вже були роботи.

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

Цикломатичні лінії складності ÷ джерела коду ( SLOC )

У вашому прикладі коду цей коефіцієнт дуже високий, тому що все було стисло в один рядок.

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

Посилання

Ось декілька посилань, якщо вас цікавить:

McCabe, T. and A. Watson (1994), Складність програмного забезпечення (CrossTalk: The Journal of Defense Software Engineering).

Watson, AH, & McCabe, TJ (1996). Структуроване тестування: методика тестування з використанням метрики цикломатичної складності (Спеціальна публікація NIST 500-235). Отримано 14 травня 2011 року з веб-сайту McCabe Software: http://www.mccabe.com/pdf/mccabe-nist235r.pdf

Розенберг, Л., Хаммер, Т., Шоу, Дж. (1998). Програмні показники та надійність (Матеріали Міжнародного симпозіуму IEEE з інженерії надійності програмного забезпечення). Отримано 14 травня 2011 року з веб-сайту Державного університету Пенну: http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.104.4041&rep=rep1&type=pdf

Моя думка та рішення

Особисто я ніколи не цінував стислості, лише читабельності. Іноді стислість допомагає читати, іноді - ні. Що важливіше, це те, що ви пишете дійсно очевидний код (ROC) замість коду лише для запису (WOC).

Просто для розваги, ось як я це написав би і попросив членів моєї команди написати:

if ((costIn <= 0) || (costOut <= 0)) return 0;
decimal changeAmount = costOut - costIn;
decimal changePercent = changeAmount / costOut * 100;
return changePercent;

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

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

У цьому конкретному випадку касти decimalповторюються знову і знову; напевно, було б краще загалом переписати це як щось на зразок:

var decIn = (decimal)CostIn;
var decOut = (decimal)CostOut;
return decIn > 0 && CostOut > 0 ? (decOut - decIn ) / decOut * 100 : 0;
//                  ^ as in the question

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

Хоча я не можу навести якісь конкретні дослідження з цього приводу, я б припустив, що всі ці викиди у вашому коді порушують принцип "Не повторюйтесь". Схоже, ваш код намагається зробити - це перетворити costInі costOutввести Decimal, а потім виконати деякі перевірки обґрунтованості результатів таких перетворень та виконувати додаткові операції над перетвореними значеннями, якщо перевірки проходять. Насправді ваш код виконує одну з перевірок правильності на неперетворене значення, підвищуючи ймовірність того, що costOut може містити значення, яке перевищує нуль, але менше половини розміру, ніж найменший ненульовий показник, який Decimalможе представляти. Код був би набагато зрозумілішим, якби він визначав тип змінних Decimalдля утримування перетворених значень, а потім діяв на них.

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

Я дивлюся на цей код і запитую "як може бути вартість 0 (або менше)?". Про який особливий випадок це вказує? Код повинен бути

bool BothCostsAreValidProducts = (CostIn > 0) && (CostOut > 0);
if (!BothCostsAreValidProducts)
  return NO_PROFIT;
else {
   // that calculation here...
}

Я здогадуюсь, як тут називаються: зміни BothCostsAreValidProductsі, NO_PROFITяк годиться.

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

1. Виконайте вимоги бізнесу з найменшим обсягом роботи

2. Уникайте помилок

3. Дозвольте нам внести зміни в майбутньому, які продовжують виконувати 1 та 2

Це цілі. Будь-який принцип чи метод проектування (будь то KISS, YAGNI, TDD, SOLID, докази, типові системи, динамічне метапрограмування тощо) є лише доброчесними, наскільки вони допомагають нам досягти цих цілей.

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

У лінійці є три питання: гвардія (спеціальний кожух 0), типове лиття та розрахунок. Кожне занепокоєння досить просте, якщо прийняти його ізольовано, але, оскільки всі вони змішані в одному виразі, це стає важко дотримуватися.

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

Оскільки CostInпризначається перед порівнянням з 0, я вважаю, що це значення з плаваючою комою. (Якби це був int, не було б підстав для того, щоб кинути). Але якщо CostOutfloat, то код може приховати неясну помилку поділу на нуль, оскільки значення плаваючої крапки може бути невеликим, але не нульовим, але нульовим при передачі на десяткове значення (принаймні, я вважаю, що це було б можливо).

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

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

Стислість - це зовсім не чеснота. Читання - це чеснота.

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

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

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

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

decimal dIn = (decimal)CostIn;
decimal dOut = (decimal)CostOut;
return dIn > 0 && CostOut > 0 ? ((dOut - dIn) / dOut) * 100 : 0;

(Редагувати: це той самий код, що й інша відповідь, тому ви йдете.)

Я шанувальник потрійного оператора ? :, тому я б залишив це в.

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

return ((decimal)CostIn > 0 && CostOut > 0) ?
       100 * ( (decimal)CostOut - (decimal)CostIn ) / (decimal)CostOut:
       0;

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

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

Я б написав це так:

return (decimal)CostIn > 0 && CostOut > 0 
            ? (((decimal)CostOut - (decimal)CostIn) / (decimal)CostOut) * 100 
            : 0;

Залежно від типу типу CostInта типу з CostOutплаваючою комою чи інтегрального типу, деякі з них можуть також бути непотрібними. На відміну від floatі double, цілісні значення неявно сприяють decimal.

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

І якщо я правильно прочитав код, то він намагається зробити підрахунок валової вартості.

var totalSales = CostOut;
var totalCost = CostIn;
var profit = (decimal)(CostOut - CostIn);
var grossMargin = 0m; //profit expressed as percentage of totalSales

if(profit > 0)
{
    grossMargin = profit/totalSales*100
}

Я припускаю, що CostIn * CostOut є цілими числами
Ось так я б написав
M (Гроші) десяткові

return CostIn > 0 && CostOut > 0 ? 100M * (CostOut - CostIn) / CostOut : 0M;

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

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

Стислість - це вже не чеснота, коли

• Є Відділення без попередньої перевірки нуля.
• Немає перевірки на нуль.
• Прибирання немає.
• Спробуй CATCH проти викидає ланцюг харчування, де можна впоратися з помилками.
• Висловлюються припущення про порядок виконання асинхронних завдань
• Завдання з використанням затримки замість перепланування в майбутньому
• Зайве використання ІО
• Не використовується оптимістичне оновлення

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

Очевидно, що помилка в коді показує, що існує ще одна проблема з Q / A, яка була недоглядом, тому той факт, що виникла помилка, не викликає проблем.

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

Спробуйте забезпечити стандартизовану реалізацію коду (стандартів та конвенцій), щоб забезпечити "читабельність" та легкість "ремонтопридатності". Але якщо ці атрибути якості не будуть визначені та не застосовуються, тоді ви отримаєте код, як у наведеному вище прикладі.

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