Нашли или выдавили из себя код, который нельзя назвать нормальным, на который без улыбки не взглянешь? Не торопитесь его удалять или рефакторить, — запостите его на говнокод.ру, посмеёмся вместе!
+141
private void tlistObject_SelectedIndexChanged(object sender, EventArgs e)
{
IMapObject oTarget = this.tlistObjects.SelectedItem as IMapObject;
if (oTarget != null)
{
if (this.SelectedObject != null)
{
this.SelectedObject.ObjectMode = ObjectModeElements.None;
}
this.SelectedObject = this.tlistObjects.SelectedItem as IMapObject;
this.SelectedObject.ObjectMode = ObjectModeElements.Selected;
}
}
(Is + Explicit приведение) или (As + проверка на Null)?
Ход конём.
ОБЯЗАТЕЛЬНОЕ использование this при обращении к полям, свойствам и методам текущего класса - отдельная тема. Это одна из особенностей неповторимого стиля, присущего аффтару. Весь код забит thisами под завязку.
Запостил: 
ICELedyanoj,
10 Февраля 2012
Follow us!
Ну и плюс thisы.
Да, и имена переменных. oTarget, oItem, iResult... - тоже часть авторского стиля.
Это расово-верный, единственно-правильный безопасный способ приведения object к типу.
Достаточно один раз привести объект через AS, присвоить результат в oTarget, проверить результат на Null и после этого SelectedObject = oTarget. Два раза-то приводить зачем? На всякий случай?
второй as не заметил
С ними код не читается.
This все из-за это.
Двойное приведение через As приводит к двойной операции упаковки, что мало-мало добавляет работы мусорщику.
VS
oMapData.Add(_tempObject.id, new DirectionPointData(_tempObject.id, _tempObject, null, oRowView["pr211"].ToString(), oRowView["pr212"].ToString(), oRowView["pr222"].ToString(), oRowView["pr231"].ToString(), _currentColor, oImageTmp, null));
-------------------
this._currentColor = this.YellowColor;
--------------------
this.map.AddRoute(this._currentRoute, oDir, this._proxy, new DirectionPointTooltipSettings(iMode, this._monitoringFormSettings.RoutesShowP ointNumber, this._monitoringFormSettings.RoutesShowA ctualTime, this._monitoringFormSettings.RoutesShowE stimateTime, this._monitoringFormSettings.RoutesShowP ointStatus, true, this._monitoringFormSettings.RoutesShowP rocessingTime, true));
Даже не знаю как ответить.
все instance-свойства вызывать через this.PropertyName
В нашей компании никто таким не страдает (уже). Первого и последнего страдальца выперли, а нам теперь после него кучу кода переделывать. This и двойное приведение - только цветочки.
1. Для квалификации элементов, скрытых одинаковыми именами.
2. Для передачи другим методам объекта в качестве параметра, например:
CalcTax(this);
3. Для объявления индексаторов.
Если вы не видите ничего плохого в распухании кода за счет ненужных ключевых слов, то даже не буду пытаться еще раз.
class MyForm : Form
{
public MyForm()
{
InitializeComponent();
.....
Какой-то код
.....
this.InitializeComponent();
}
}
Теперь скажите, что принудительное использование this делает код более читаемым.
Такое использование this не запрещается, но нигде в том же MSDN я не видел кода с обращением к каждому полю через this.
Основная причина распухания кода - неумение его организовать, а уж никак не использование this.
fixed
А два - правильное именование переменных класса легко сводит количество таких случаев к нулю.
В нашем коде все приватные поля и свойства класса именуются по типу "_name", пабликовые - "Name", входящие аргументы - "name". Поэтому:
1. При взгляде на имя всегда понятно чье это (и this не нужен для этого, аргумент от поля легко отличить).
2. Имена аргументов и переменных класса никогда не совпадают, будучи при этом одинаковыми (как ни парадоксально).
Где вы увидели попытки слива? В согласии с мыслью о необходимости одинаковых имен аргументов и полей? Тогда прошу перечитать мой комментарий ещё раз.
Если я так уж неправ, то прошу вас аргументировать свою любовь к избыточному коду.