Ну, короче, сразу в холиварах!  

Утекло отсюда. Конкретно тут, отвечающих "Да", ласково проименовали дятлами.  

P.S. Сам - дятел.  

Это сообщение отредактировал(а) kemiisto - 8.6.2009, 17:23

А что такое сишные языки?

Ну я хотел было написать C-style based syntax languages. Но чёт сложно больно. Короче, языки, унаследовавшие синтаксические "нюансы" C.

Добавлено @ 15:54

Так, ну эт был наш безошибочный NightmareZ.  

Это сообщение отредактировал(а) kemiisto - 8.6.2009, 15:58

Давайте, например, вместо "+" писать "plus". А то какой-нить бедный несчастный ребёнок ошибётся.
Сделаем UberPascal:

NightmareZ, я тоже тебя минусую!  

Было. Пару раз. Но это никак не повод менять что-то в синтаксисе.

ППКС.

бывало....

Было, куда без этого. Теперь в случае выдачи ненормальных результатов прогой первым делом проверяю ифы, ибо потом забудешь и убьешь бешеное количество времени на поиск ошибок. Хотя отладка спасает все же в таких случаях всегда)

"Нет" на такой вопрос может ответить только тот, кто кроме сишного синтаксиса никаких других и не знает, да и то далеко не каждый.  Так что опрос, имхо, бессмысленный. Особенно если учесть, что if (a=b) - это один из самых распространённых багов сишных программ, наряду с проваливающимися case-statement и арифметикой указателей. Настолько распространённый, что C# такой код даже не компилирует и правильно делает.

Добавлено через 1 минуту и 6 секунд
ну так об этом речь и не идёт...

А аналог такого кода скомпилит:



Java этот код скомпилит, но если a и b будут чем угодно, кроме boolean, то не скомпилит, так как if требует, что бы результирующее выражение в скобках было boolean.

п.с. по САБЖу - бывало  

На мой взгляд, проблема не столько в выборе символов для операторов присваивания и сравнения, сколько в том, что в Си assignment statement является expression (пишу по-английски, чтобы не было вопросов, под «оператором» подразумевается operator или statement).
Ради сомнительной возможности писать цепочки присваиваний вида

(чего, кстати, в Python добились, не превращая присваивание в выражение) и экономить одну строчку на условиях или циклах вида

ввели новый класс ошибок.
Хотя опасность проблемы часто преувеличивают. Багов, связанных с указателями и управлением памятью, намного больше.

Это сообщение отредактировал(а) Void - 8.6.2009, 20:22

  


Это сообщение отредактировал(а) kemiisto - 8.6.2009, 21:08

В принципе, это стандартное свойство C-подобных языков - компактность исходника превыше всего, в том числе читаемости и "ошибкоемкости". К сожалению, начинающие программисты обычно это любят, а понимание сложностей разработки и поддержки кода на таком языке приходит (если вообще приходит) намного позже, отсюда и популярность этих языков.

Бывало. Но с нормальными компиляторами такие баги живут обычно до первой компиляции.

у меня жили дольше. долго ловил поначалу)))

меня в "школе" учили:

• если сравниваем переменные с константами, то константу пишем ВСЕГДА слева: Если по ошибке забываем второй знак равенства, программа не компилируется.
• избегать сравнения переменных в if-ax, использовать макро:
  у каждогоо типа своя сравнилка
  • при дебаге в глаза бросается сравнение IS_SHAPE_EQUAL(color1,color2)
  • при проблеме в макро легче отловить одинаковый баг в макро, чем 1 единственное сравнение в одном из if-ов
  • в принципе это почти объектно ориентированный подход...

nickless, угу. внимательно стоит читать предупреждения компилятора. Хотя я ответила "Да" но для меня это не становилось проблемой. 

Абсолютно не поддерживаю такой подход 

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

Не было никогда. Не пишу на сабжевых языках.

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

интересно.. пользовался ли кто нить из живых людей вижуал или просто бэйсиком в мс офисе? оч. советую - ощющение просто непередаваемое, когда после каждой незакрытой скобки появляется ненавящивое диалоговое окно, мол "незабудьте закрыть скобку", и это в момент когда я хочу скопирывать туда из другого места какоето выражение.., пока незакроешь это окно ничего у тебя невыйдет !!

но эт так крик души  и   

Это сообщение отредактировал(а) zloyGamer - 13.6.2009, 17:20

было 2 раза.


Любитель
  Согласен только с константой слева

Раньше бывало, сейчас уже отучил себя вроде. Наоборот, случалось в MySql писать ==  О чем он сразу сообщал.

ок.
ткни мной в альтернативу, пожалста.

Альтернатива - писать обычные сравнения. Мест, где можно ошибиться всегда полно (x с y перепутать там..) - это не повод изменять синтаксис. Лично я, когда встречаю код с "обратным" сравнением - всегда мысленно ругаюсь.. Уж не знаю почему - всопринимается/читается такой код хуже.. Конечно, дело вкуса, но, думаю многие со мной согласятся.

понятно. 
на полном серьёзе хотел увидеть какое-то объективное преимущество.
но если единственное что приходит на ум это "дело вкуса", то я остаюсь со своими тараканами 

Для меня (!) преимущество в том, что подобный код (сравнения с константой слева, макросы и пр.) я буду читать дольше. "Одним взглядом" оценить точно не смогу..

Неудивительно, подобные выверты нарушают семантику кода. Само утверждение "если константа равна чему-то" абсурдно, константа равна только сама себе, на то она и константа и никаких "если" быть по определению не может. 
Что касается макросов аля IS_SHAPE_EQUAL, то они затрудняют чтение кода а их названия являются мусором с семантической точки зрения. Да, часто имеет смысл в if вызывать функцию, но название этой функция должно показывать смысл условного выражения, простейший пример: is_odd(x) вместо тупого IS_INTEGER_EQUAL(x%2, 1) или ужасного 1==x%2.
Так что рекомендации:


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

Вечер добрый!

Долго ли, коротко ли, дошли у меня руки до книжки по ++. Купил по совету людей добрых Х. М. Дейтел, П. Дж. Дейтел
Как программировать на C++, 5-е издание. Объём книги 1500 страниц. Ну а что? "Шок - это по-нашему!" 

Так вот, там есть целый раздел: 5.9. Случайная подмена операции равенства (==) присваиванием (=). Начинается раздел какбэ с обращения к NightmareZ'у:

  Молодцы парни!  
Ну там дальше тыры-пыры, про особенности С++, которые ухудшают положение дел, ... А дальше совет по предотвращению ошибки: 


И так большая часть книжки - сначала авторы расскажут про очередную приплюснутую чушь, потом гениальный совет (обычно из серии "Семь бед - один ответ", типа прислушивайтесь к сообщению компилятора, будьте внимательны, ...)  Оборжака, короче.

Но! Это ещё не всё комрады. Во введении авторы жгут по полной:


Теперь, усядьтесь-ка поудобнее, вспомните Михал Николаича Задорнова... Вспомнили? Наберите воздуха в грудь... Уф... Эпиграф к предисловию книги:
 

Я плачу...   

Было конечно, но сразу же находилось.
А вот в питоне этого нету, и я аж от злости поносом изошелся, когда искал варианты, как это можно похакать. Не нашел =\

Не помню у кого. Но в статье была рекомендация. Заместо

Писать

Тогда уже на стадии компиляции будут отлавливаться такие ошибки. Хотя я каюсь . Такую технику преминяю крайне редко. Мне все таки более привычен 1 способ. Привычки менять тяжело.

писал, и довольно часто
и отлавливалось это иногда довольно сложно
согласен, что надо писать if(CONST==var) потому что от этого повышается ошибкоустойчивость кода

то что оно "плохо читается"  - это субъективный аргумент.
аргумент из разряда "код С++ неудобно читать". кому то  и классы плохо читаются. 
а вот то что вероятность появления такой ошибки значительно уменьшается - это объективный факт.