Почему я не должен использовать «с» в Delphi?

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

Насколько я знаю, это ничего не ускоряет, хотя - это - чисто синтаксический сахар.

Мне не нравится он, потому что это делает отлаживание стычки. Вы не можете считать значение переменной и т.п., просто нависнув над ним с мышью.

Эти дебаты происходят в JavaScript много также.

В основном, который С синтаксисом делает его очень трудно для сообщения сразу, к какому свойству/методу Left/Top/etc Вы обращаетесь. У Вас могла быть локальная переменная под названием Левый, и свойство (это было некоторое время, так как я сделал Дельфи, жаль, если имя является неправильным), названный Левым, возможно, даже функция под названием Левый. Любой читающий код, кто не супер знаком со структурой ARect, мог быть очень очень потерян.

Одно раздражение с использованием с - то, что отладчик не может обработать его. Таким образом, это делает отладку более трудной.

А большая проблема состоит в том, что менее легко прочитать код. Особенно, если с оператором немного длиннее.

procedure TMyForm.ButtonClick(...)
begin
  with OtherForm do begin
    Left := 10;
    Top := 20;
    CallThisFunction;
  end;
end;

, Которым назовут CallThisFunction Формы? Сам (TMyForm) или OtherForm? Вы не можете знать, не проверяя, имеет ли OtherForm метод CallThisFunction.

И самая большая проблема то, что можно сделать ошибки легкими, даже не зная это. Что, если и TMyForm и OtherForm имеют CallThisFunction, но это является частным. Вы могли бы ожидать/хотеть OtherForm. CallThisFunction, который назовут, но это действительно не. Компилятор предупредил бы Вас, если Вы не использовали с, но теперь он не делает.

Используя несколько объектов в с умножает проблемы. См. http://blog.marcocantu.com/blog/with_harmful.html

Я предпочитаю синтаксис VB в этом случае, потому что здесь, необходимо снабдить префиксом участников в с блоком с . для предотвращения неоднозначностей:

With obj
    .Left = 10
    .Submit()
End With

, Но действительно, нет ничего неправильно с with в целом.

Маловероятно, что "со" сделал бы код выполненным быстрее, более вероятно, что компилятор скомпилировал бы его в тот же исполняемый код.

главная причина, с которой не любят люди, состоит в том, что это может представить беспорядок об объеме пространства имен и приоритете.

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

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

Это разрешает некомпетентным или злым программистам писать код unreadble. Для этого только используйте эту функцию, если Вы не являетесь ни некомпетентными, ни злыми.

Что Вы сохраняете во вводе, Вы проигрываете в удобочитаемости. Много отладчиков не будут иметь подсказки, что Вы отсылаете к любому настолько отлаживающему, является более трудным. Это не делает программы выполненными быстрее.

Считают создание кода в Вашем с оператором методом объекта, к которому Вы обращаетесь.

На работе мы даем точки для удаления Withs от существующей кодовой базы Win 32 из-за дополнительного усилия, должен был поддержать код, который использует их. Я нашел несколько ошибок в предыдущем задании, где локальная переменная под названием BusinessComponent была замаскирована, будучи в С, начинают блок для объекта что опубликованное свойство BusinessComponent того же типа. Компилятор принял решение использовать опубликованное свойство и код, который означал использовать разрушенную локальную переменную.

я видел, что код как

С a, b, c, d делает {кроме, они - намного более длинные имена, просто сокращенный здесь) начинают меня: = xyz;
конец;

Это может быть реальная боль, пытающаяся располагаться, куда xyz прибывает из. Если это был c, я записал бы это как

я: = c.xyz;

Вы думаете, что это довольно тривиально для понимания этого, но не в функции, которая была 800 строками долго, которые использовали с прямо в запуске!

Мы недавно запретили его в нашем Delphi, кодирующем stnadards.

профессионалы часто перевешивали недостатки.

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

Да, с помощью с банкой, ведомой к (мягко) более быстрому выполнению кода.

В следующем, нечто только оценено однажды:

with foo do
begin
  bar := 1;
  bin := x;
  box := 'abc';
end

, Но, здесь это оценено три раза:

foo.bar := 1;
foo.bin := x;
foo.box := 'abc';

... выполненный быстрее...

Не обязательно - Ваш компилятор/интерпретатор обычно лучше в оптимизации кода, чем Вы.

я думаю, что это заставляет меня сказать "фу!" потому что это лениво - когда я читаю код (особенно чужой), мне нравится видеть явный код. Таким образом, я даже записал бы "this.field" вместо "поля" в Java.

Было бы здорово, если бы оператор with был расширен следующим образом:

with x := ARect do
begin
  x.Left := 0;
  x.Rigth := 0;
  ...
end;

Вы бы не нужно объявить переменную 'x'. Он будет создан компилятором. Писать быстро и не путать, какая функция используется.

Это в первую очередь проблема обслуживания.

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

Например, если у нас есть небольшая функция foo, которая содержит три или четыре строки кода, которые были заключены в блок WITH, тогда действительно нет проблем. Однако несколько лет спустя эта функция могла быть расширена под руководством нескольких программистов до 40 или 50 строк кода, все еще заключенных в WITH. Сейчас это непросто, и уже пора вносить ошибки, особенно если сопровождающий начинает вводить дополнительные встроенные блоки WITH.

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

Вы можете комбинировать с операторами, так что вы получите

with Object1, Object2, Object3 do
begin
  //... Confusing statements here
end

И если вы думаете, что отладчик сбит с толку одним с, я не понимаю, как кто-то может определить, что происходит в , с помощью блок

Для Delphi 2005 существует жесткая ошибка в операторе with-do - указатель оценки потерян и повторите попытку с указателем вверх. Здесь необходимо использовать локальную переменную, а не тип объекта напрямую.