Неправильное отображение исключения. Чтобы повторно вызвать исключение:

try
{
    // do some stuff here
}
catch (Exception ex)
{
    throw ex;  // INCORRECT
    throw;     // CORRECT
    throw new Exception("There was an error"); // INCORRECT
    throw new Exception("There was an error", ex); // CORRECT
}

GC.Collect() собирать вместо того, чтобы доверять сборщику мусора.

Я слишком часто вижу это как в Java, так и в C # ...

if(something == true){
  somethingelse = true;
}

с бонусными баллами, если у него также есть

else{
  somethingelse = false;
}

using Microsoft.SharePoint;

'достаточно

Я часто вижу следующий код:

if (i==3)
       return true;
else
       return false;

должно быть:

       return (i==3);

Оскорбление закона Деметры:

a.PropertyA.PropertyC.PropertyB.PropertyE.PropertyA = 
     b.PropertyC.PropertyE.PropertyA;

Бросок NullReferenceException:

if (FooLicenceKeyHolder == null)
    throw new NullReferenceException();

Это правда, я видел это собственными глазами.

public object GetNull()
{
     return null;
}

На самом деле он использовался в приложении, и даже имел вместе с ним хранимую процедуру, sp_GetNull, которая возвращала бы null ....

это сделало мой день.

Я думаю, что sp использовался для классического сайта asp .. что-то связано с набором результатов. в .net была идея "конвертировать" код в .net ...

int foo = 100;
int bar = int.Parse(foo.ToString());

Или более общий случай:

object foo = 100;
int bar = int.Parse(foo.ToString());

Я нашла это в нашем проекте и чуть не сломала стул ...

DateTime date = new DateTime(DateTime.Today.Year, 
                             DateTime.Today.Month, 
                             DateTime.Today.Day);

Довольно часто я натыкаюсь на такого рода злоупотребления варом:

var ok = Bar();

или даже лучше:

var i = AnyThing();

Использование var таким образом не имеет смысла и ничего не дает. Это просто усложняет соблюдение кода.

• Отсутствие нулевого теста перед вызовом делегата.
• Незнание, когда и как использовать «as» с проверкой на null по сравнению с приведением с помощью try / catch.
• «исключить исключение» или «выбросить» в блоке catch.
• Создание большого количества строк вместо использования StringBuilder.
• Глубокая вложенность используемых блоков.

Непонимание того, что bool - это реальный тип, а не просто соглашение

if (myBooleanVariable == true)
{
    ...
}

или, что еще лучше

if (myBooleanVariable != false)
{
    ...
}

Подобные конструкции часто используются C и C++ разработчиками, где идея логического значения была просто условием (0 == ложь, все остальное верно); в C # или других языках с настоящими логическими значениями это не обязательно (или нежелательно).

Обновлено: последний абзац перефразирован для большей ясности.

Открытые переменные в классах (вместо этого используйте свойство).

Если класс не является простым объектом передачи данных.

См. комментарии ниже для обсуждения и пояснений.

Я действительно видел это.

bool isAvailable = CheckIfAvailable();
if (isAvailable.Equals(true))
{ 
   //Do Something
}

превосходит isAvailable == true анти-паттерн!
Делаем это супер-анти-паттерном!

Частные автоматически реализованные свойства:

private Boolean MenuExtended { get; set; }

Объявление и инициализация всех локальных переменных в начале каждого метода - это ужасно!

void Foo()
{
    string message;
    int i, j, x, y;
    DateTime date;

    // Code
}

Двухстрочный анти-шаблон
Анти-шаблон № 1
Проверка строк на ноль или пустоту

//Bad
if( myString == null || myString == "" )
OR
if( myString == null || myString.Length == 0 )

//Good
string.IsNullOrEmpty(myString)

Anti-Pattern # 2 (только для .NET 4.0)
Проверка строк на наличие нуля, пустого или пробела

//Bad
if( myString == null || myString == "" || myString.Trim() == "")

//Good
string.IsNullOrWhiteSpace(myString) 

Излишнее преобразование (доверьтесь компилятору):

foreach (UserControl view in workspace.SmartParts)
{
  UserControl userControl = (UserControl)view;
  views.Add(userControl);
}

if(data != null)
{
  variable = data;
}
else
{
  variable = new Data();
}

может быть лучше записано как

variable = (data != null) ? data : new Data();

и даже лучше написано как

variable = data ?? new Data();

Последний листинг кода работает в .NET 2.0 и выше.

Меня всегда улавливала речь с акцентом.

Программисты на C ++:

if (1 == variable) { }

В C # это приведет к ошибке компилятора, если вы наберете if (1 = variable), что позволит вам написать код именно так, как вы это имеете в виду, вместо того, чтобы беспокоиться о том, чтобы выстрелить себе в ногу.

Я вижу, что не использую тернарный язык, преобразователи в C # иногда делают

понимаете:

private string foo = string.Empty;
if(someCondition)
  foo = "fapfapfap";
else
  foo = "squishsquishsquish";

вместо:

private string foo  = someCondition ? "fapfapfap" : "squishsquishsquish";

Доступ к измененным закрытиям

foreach (string list in lists)
{
        Button btn = new Button();
        btn.Click += new EventHandler(delegate { MessageBox.Show(list); });
}

(см. ссылку для объяснения и исправления)

Для объединения произвольного количества строк с использованием объединения строк вместо построителя строк

Примеры

foreach (string anItem in list)
    message = message + anItem;

это считается общим?

public static main(string [] args)
{
  quit = false;
  do
  {
  try
  {
      // application runs here .. 
      quit = true;
  }catch { }
  }while(quit == false);
}

Я не знаю, как это объяснить, но это похоже на то, что кто-то улавливает исключение и повторяет код снова и снова, надеясь, что это сработает позже. Например, если возникает исключение IOException, они просто пытаются снова и снова, пока он не сработает.

В проекте, над которым я работаю, было пятьдесят классов, все унаследованные от одного и того же класса, который был определен всеми:

public void FormatZipCode(String zipCode) { ... }

Либо поместите его в родительский класс, либо в служебный класс в сторону. Ага.

Думали ли вы о просмотре The Daily WTF?

Чрезвычайно сложные методы Page_Load, которые хотят делать все.

Использование свойств для чего-либо, кроме простого извлечения значения или, возможно, недорогого вычисления. Если вы обращаетесь к базе данных из своего ресурса, вам следует изменить его на вызов метода. Разработчики ожидают, что вызовы методов могут быть дорогостоящими, они не ожидают этого от свойств.

Нашел это несколько раз в системе, которую я унаследовал ...

if(condition){
  some=code;
}
else
{
  //do nothing
}

и наоборот

if(condition){
  //do nothing
}
else
{
  some=code;
}

У меня было такое раньше:

AnEnum e = AnEnum.Abc;
int i = (int)e;
// lots of code
AnEnum f = (AnEnum)Enum.Parse(i, typeof(AnEnum));

if (state == ((int)RowState.Active).ToString())
else if (state == ((int)RowState.NotActive).ToString())

state - это строковое значение сообщения, которое содержит значение из перечисления RowState.

В конце концов, именно так мы проверяем значение.

Основная проблема с .NET, похоже, заключается в том, что есть много разработчиков, пришедших из VB 6.0 или (что еще хуже, на мой взгляд, потому что они ошибочно ДОВЕРЯЮТ, что знают, что делать, в то время как программисты VB 6.0, по крайней мере, достаточно скромны, чтобы захотеть узнать что-то новое) Java / C ++.

Люди, слишком невежественные по отношению к современным парадигмам, люди, облепляющие свой код уродливым P / Invoke в худшем из возможных стилей C ++. :-(

Невежество - это блаженство (знайте свои рамки):

TimeSpan keyDays = new TimeSpan(Licence.LicenceExpiryDate.Ticks);
TimeSpan nowDays = new TimeSpan(System.DateTime.Now.Ticks);

int daysLeft = keyDays.Days - nowDays.Days;

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

Я видел несколько недавно.

Никогда не заканчивающаяся цепочка параметров

public string CreateJob(string siteNumber, string customer, string jobType, string description, string reference, string externalDoc, string enteredBy, DateTime enteredDateTime)
    {
        //recordtype = 0 for job
        //load assignments and phases set to false
        return Create(0, siteNumber, customer, jobType, description, reference, externalDoc, enteredBy, enteredDateTime, false, false);
    }

public string Create(int recordType, string siteNumber, string customer, string jobType, string description, string reference, string externalDoc, string enteredBy, DateTime enteredDateTime, bool loadAssignments, bool loadPhases)
{
    _vmdh.Fields.FieldByName("WDDOCTYPE").SetValue(recordType, false);
    _vmdh.Fields.FieldByName("NMDOCID").SetValue(-1, false);
    _vmdh.Init();           
        ....
        ...
        // And it keeps going
    }

Интересно, что происходит при закрытии формы?

 private void frmAddImages_FormClosing(object sender, FormClosingEventArgs e)
{
    if (DialogResult != DialogResult.OK)
    {
        if (IsDirty)
        {
            e.Cancel = !(MessageBox.Show("Are you sure that you want to exit without saving", "Form Not Saved", MessageBoxButtons.YesNo) == DialogResult.Yes);
        }
    }
    }

Строчно набранный

switch (cbDateFilter.Text)
            {
                case "This Week":
                    dt = DateTime.Now;
                    while (dt.DayOfWeek != DayOfWeek.Monday) dt = dt.AddDays(-1); //find first day of week
                    dtFrom.Value = DateTime.Parse(dt.ToString("dd/MM/yyyy 00:00:00"));
                    dtTo.Value = DateTime.Parse(dt.AddDays(6).ToString("dd/MM/yyyy 23:59:59"));
                    break;

                case "This Month":
                    dt = DateTime.Now;
                    while (dt.Day != 1) dt = dt.AddDays(-1); // find first day of month
                    dtFrom.Value = DateTime.Parse(dt.ToString("dd/MM/yyyy 00:00:00"));
                    dtTo.Value = DateTime.Parse(dt.AddMonths(1).AddDays(-1).ToString("dd/MM/yyyy 23:59:59"));
                    break;

                case "This Quarter":
                    // if at end of Quarter then we need subtract -4 to get to priv Quarter
                    dt = DateTime.Now;
                    while (dt.Month != 7 &&
                        dt.Month != 10 &&
                        dt.Month != 1 &&
                        dt.Month != 4) dt = dt.AddMonths(-1); //find first month, fiscal year
                    while (dt.Day != 1) dt = dt.AddDays(-1); // find first day on month
                    dtFrom.Value = DateTime.Parse(dt.ToString("dd/MM/yyyy 00:00:00"));
                    dtTo.Value = DateTime.Parse(dt.AddMonths(3).AddDays(-1).ToString("dd/MM/yyyy 23:59:59"));
                    break;

Использование (плохо)

IEnumerable<Bar> foo = ...
if (foo.Count() > 0)
{
    ...
}

вместо (хорошо)

IEnumerable<Bar> foo = ...
if (foo.Any())
{
    ...
}

чтобы проверить, содержит ли что-нибудь IEnumerable. Count() должен пройти через всю коллекцию с помощью MoveNext(), в то время как Any() должен вызвать MoveNext() только один раз.

Чрезмерное использование / злоупотребление инициализаторами объектов для всего, вероятно, из-за лени:

var person = new Person
{
    FirstName = "joe",
    (... lots of setters down here)
};

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