Чому слід уникати операторів збільшення ("++") та скорочення ("-") в JavaScript?

Однією з порад щодо інструменту jslint є:

++ і -
Оператори ++ (приріст) та - (декремент), як відомо, сприяють поганому коду, заохочуючи надмірну хитрість. Вони посідають лише недосконалу архітектуру в наданні вірусів та інших загроз безпеці. Існує опція plusplus, яка забороняє використання цих операторів.

Я знаю, що подібні конструкції PHP $foo[$bar++]можуть легко спричинити помилки за одним, але я не міг придумати кращий спосіб керувати циклом, ніж a while( a < 10 ) do { /* foo */ a++; }або for (var i=0; i<10; i++) { /* foo */ }.

Чи підкреслює їх jslint через те, що є деякі подібні мови, яким не вистачає синтаксису " ++" і " --", або обробляти його по-різному, чи є інші обґрунтування для уникнення " ++" і " --", які мені можуть бути відсутні?

На мій погляд, завжди використовувати ++ і - самостійно в одному рядку, як у:

i++;
array[i] = foo;

замість

array[++i] = foo;

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

Мене відверто бентежить ця порада. Частина мене замислюється, чи не пов’язано це з відсутністю досвіду (сприйманого чи фактичного) з кодерами JavaScript.

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

У C є історія таких дій, як:

while (*a++ = *b++);

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

І завжди виникає питання про що

++i = i++;

або

i = i++ + ++i;

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

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

Якщо ви прочитаєте JavaScript The Good Parts, ви побачите, що заміна Крокфорда на i ++ в циклі a for є i + = 1 (не i = i + 1). Це досить чисто і читабельно, і з меншою ймовірністю перетворюється на щось "складне".

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

Моє особисте правило - не робити нічого в поєднанні з автоматичним посиленням або автоматичним посиленням.

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

Тож, для моїх власних правил, використання i ++ як приросту в циклі for є прекрасним.

У циклі це нешкідливо, але в заяві про призначення це може призвести до несподіваних результатів:

var x = 5;
var y = x++; // y is now 5 and x is 6
var z = ++x; // z is now 7 and x is 7

Пробіл між змінною та оператором також може призвести до несподіваних результатів:

a = b = c = 1; a ++ ; b -- ; c; console.log('a:', a, 'b:', b, 'c:', c)

На завершення, несподівані результати також можуть бути проблемою:

var foobar = function(i){var count = count || i; return function(){return count++;}}

baz = foobar(1);
baz(); //1
baz(); //2


var alphabeta = function(i){var count = count || i; return function(){return ++count;}}

omega = alphabeta(1);
omega(); //2
omega(); //3

І це запускає автоматичне вставлення крапки з комою після нового рядка:

var foo = 1, bar = 2, baz = 3, alpha = 4, beta = 5, delta = alpha
++beta; //delta is 4, alpha is 4, beta is 6

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

Список літератури

• Довідка JSLint: Оператори збільшення та скорочення

Розглянемо наступний код

    int a[10];
    a[0] = 0;
    a[1] = 0;
    a[2] = 0;
    a[3] = 0;
    int i = 0;
    a[i++] = i++;
    a[i++] = i++;
    a[i++] = i++;

оскільки я ++ оцінюється вдвічі, то вихід (від налагоджувача vs2005)

    [0] 0   int
    [1] 0   int
    [2] 2   int
    [3] 0   int
    [4] 4   int

Тепер розглянемо наступний код:

    int a[10];
    a[0] = 0;
    a[1] = 0;
    a[2] = 0;
    a[3] = 0;
    int i = 0;
    a[++i] = ++i;
    a[++i] = ++i;
    a[++i] = ++i;

Зауважте, що вихід однаковий. Тепер ви можете подумати, що ++ i та i ++ однакові. Вони не

    [0] 0   int
    [1] 0   int
    [2] 2   int
    [3] 0   int
    [4] 4   int

Нарешті розглянемо цей код

    int a[10];
    a[0] = 0;
    a[1] = 0;
    a[2] = 0;
    a[3] = 0;
    int i = 0;
    a[++i] = i++;
    a[++i] = i++;
    a[++i] = i++;

Вихід зараз:

    [0] 0   int
    [1] 1   int
    [2] 0   int
    [3] 3   int
    [4] 0   int
    [5] 5   int

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

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

На мій погляд, "явне завжди краще, ніж неявне". Тому що в якийсь момент ви можете заплутатися в цьому твердженні про збільшення y+ = x++ + ++y. Хороший програміст завжди робить свій код більш читабельним.

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

З метою ефективності я віддаю перевагу:

• ++ i, коли не використовується повернене значення (без тимчасового)
• i ++ при використанні зворотного значення (без зупинки трубопроводу)

Я фанат містера Крокфорда, але в цьому випадку мені доводиться не погоджуватися. ++iце на 25% менше тексту для розбору, i+=1 і, певно, ясніше.

Я дивився відео Дугласа Крокфорда про це, і його пояснення щодо використання приросту та зменшення - це те

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

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

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

Вирази, такі як ++ + ++ b, легко розробити, якщо ви просто пам'ятаєте вище.

var a = 1, b = 1, c;
c = a ++ + ++ b;
// c = 1 + 2 = 3; 
// a = 2 (equals two after the expression is finished);
// b = 2;

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

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

Я живу, щоб бути неправдивим, хоча ...

Інший приклад, більш простий, ніж деякі інші, з простим поверненням збільшення вартості:

function testIncrement1(x) {
    return x++;
}

function testIncrement2(x) {
    return ++x;
}

function testIncrement3(x) {
    return x += 1;
}

console.log(testIncrement1(0)); // 0
console.log(testIncrement2(0)); // 1
console.log(testIncrement3(0)); // 1

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

function closureIncrementTest() {
    var x = 0;

    function postIncrementX() {
        return x++;
    }

    var y = postIncrementX();

    console.log(x); // 1
}

Я думаю, що програмісти повинні бути компетентними мовою, якою вони користуються; використовувати його чітко; і добре використовувати його. Я не думаю, що вони повинні штучно калічити мову, якою вони користуються. Я кажу з досвіду. Я колись працював буквально по сусідству з магазином Cobol, де вони не використовували ELSE "тому що це було занадто складно". Reductio ad absurdam.

Як вже згадувалося в деяких існуючих відповідях (що дратує я не можу коментувати), проблема полягає в тому, що x ++ ++ x оцінюють за різними значеннями (до vs після збільшення), що не очевидно і може бути дуже заплутано - якщо це значення використовується. cdmckay пропонує досить розумно дозволити використовувати оператор приросту, але лише таким чином, що повернене значення не використовується, наприклад, у його власному рядку. Я також включав би стандартне використання в циклі for (але тільки в третьому операторі, повернене значення якого не використовується). Я не можу придумати іншого прикладу. Будучи «спалений», я би рекомендував те саме керівництво і для інших мов.

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

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

while ( a < 10 ){
    array[a++] = val
}

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

Крім того, Крокфорд, здається, використовує i- = 1, який мені здається важче прочитати, ніж --i або i--

Мої 2 центи - це те, що їх слід уникати у двох випадках:

1) Коли у вас є змінна, яка використовується в багатьох рядках, і ви збільшуєте / зменшуєте її на першому операторі, який використовує її (або останньому, або, що ще гірше, в середині):

// It's Java, but applies to Js too
vi = list.get ( ++i );
vi1 = list.get ( i + 1 )
out.println ( "Processing values: " + vi + ", " + vi1 )
if ( i < list.size () - 1 ) ...

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

2) У випадку множини ++ і - приблизно однакова змінна в тому самому операторі. Дуже важко згадати, що відбувається у таких випадках:

result = ( ++x - --x ) * x++;

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

Фортран - мова, схожа на С? Він не має ані ++, ані -. Ось як ви пишете цикл :

     integer i, n, sum

      sum = 0
      do 10 i = 1, n
         sum = sum + i
         write(*,*) 'i =', i
         write(*,*) 'sum =', sum
  10  continue

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

      integer i

      do 20 i = 10, 1, -2
         write(*,*) 'i =', i
  20  continue

Чи схожий на Python C? Він використовує розуміння діапазону та списку та інші синтаксиси, щоб обійти необхідність збільшення індексу:

print range(10,1,-2) # prints [10,8.6.4.2]
[x*x for x in range(1,10)] # returns [1,4,9,16 ... ]

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

Чи відрізняються Fortran і Python від магніту-помилки, ніж процедурні мови, які мають ++ та -? Я не маю доказів.

Я стверджую, що Fortran і Python схожі на C, тому що я ніколи не зустрічав когось, хто вільно володів C, хто не міг би з 90% точністю відгадати правильність намірів непритомного Fortran чи Python.