DateTime current = DateTime.Parse("1/1/2009");
DateTime nextYear = current.AddYears(1);
do
{
Console.WriteLine(current);
current = current.AddDays(1);
} while (current < nextYear) ;
Повторное копирование исключение неправильно. Чтобы повторно вызвать исключение:
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
}
Доступ к измененным замыканиям
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, они просто пытаются снова и снова, пока он не сработает ..
Чрезвычайно сложные методы «Page_Load», которые хотят делать все.
GC.Collect ()
для сбора вместо того, чтобы доверять сборщику мусора.
В моем проекте было пятьдесят классов, все унаследованные от одного и того же класса, которые все определены:
public void FormatZipCode(String zipCode) { ... }
Либо поместите его в родительский класс, либо утилитарный класс в стороне. Аргх.
Вы рассматривали возможность просмотра The Daily WTF ?
Я слишком много вижу этого, как в Java, так и в C # ...
if(something == true){
somethingelse = true;
}
с бонусными баллами, если он также имеет
else{
somethingelse = false;
}
Я часто вижу следующий код:
if (i==3)
return true;
else
return false;
должен быть:
return (i==3);
Оскорбление закона Деметры:
a.PropertyA.PropertyC.PropertyB.PropertyE.PropertyA =
b.PropertyC.PropertyE.PropertyA;
Я нашел это в нашем проекте и чуть не сломал стул ...
DateTime date = new DateTime(DateTime.Today.Year,
DateTime.Today.Month,
DateTime.Today.Day);
int foo = 100;
int bar = int.Parse(foo.ToString());
Или более общий случай:
object foo = 100;
int bar = int.Parse(foo.ToString());
Довольно часто я натыкаюсь на такого рода злоупотребление var:
var ok = Bar();
или даже лучше:
var i = AnyThing();
Использование var таким способом не имеет смысла и ничего не дает. Это только усложняет соблюдение кода.
Это правда, я видел это собственными глазами.
public object GetNull()
{
return null;
}
На самом деле он использовался в приложении, и даже имел вместе с ним хранимую процедуру, sp_GetNull, которая возвращала бы null ....
, которые сделали мой день.
Я думаю, что sp использовался для классического asp-сайта .. что-то связано с набором результатов. в .net была идея "конвертировать" код в .net ...
Непонимание того, что bool - это реальный тип, а не просто соглашение
if (myBooleanVariable == true)
{
...
}
или, что еще лучше,
if (myBooleanVariable != false)
{
...
}
Подобные конструкции часто используются в C
и ] Разработчики на C ++
, в которых идея логического значения была просто условностью (0 == false, все остальное верно); это не обязательно (или нежелательно) в C # или других языках, которые имеют настоящие логические значения.
Обновлено : перефразирован последний абзац, чтобы улучшить его ясность.
Открытые переменные в классах (используйте вместо этого свойство).
Если класс не является простым объектом передачи данных.
См. Комментарии ниже для обсуждения и пояснения.
]object variable;
variable.close(); //Old code, use IDisposable if available.
variable.Dispose(); //Same as close. Avoid if possible use the using() { } pattern.
variable = null; //1. in release optimised away. 2. C# is GC so this doesn't do what was intended anyway.
Объявление и инициализация всех локальных переменных в начале каждого метода ужасно!
void Foo()
{
string message;
int i, j, x, y;
DateTime date;
// Code
}
Частные автоматически реализуемые свойства:
private Boolean MenuExtended { get; set; }
Я вижу, что не используется тройной код, иногда конвертируется в C #
вы видите:
private string foo = string.Empty;
if(someCondition)
foo = "fapfapfap";
else
foo = "squishsquishsquish";
вместо:
private string foo = someCondition ? "fapfapfap" : "squishsquishsquish";
Нашел это несколько раз в унаследованной мной системе ...
if(condition){
some=code;
}
else
{
//do nothing
}
и наоборот
if(condition){
//do nothing
}
else
{
some=code;
}
if(data != null)
{
variable = data;
}
else
{
variable = new Data();
}
can be better written as
variable = (data != null) ? data : new Data();
and even better written as
variable = data ?? new Data();
Last code listing works in .NET 2.0 and above
Бесполезное преобразование (доверяйте компилятору):
foreach (UserControl view in workspace.SmartParts)
{
UserControl userControl = (UserControl)view;
views.Add(userControl);
}
Выбрасывание NullReferenceException
:
if (FooLicenceKeyHolder == null)
throw new NullReferenceException();
I have actually seen this.
bool isAvailable = CheckIfAvailable();
if (isAvailable.Equals(true))
{
//Do Something
}
beats the isAvailable == true
anti-pattern hands down!
Making this a super-anti-pattern!
Двухстрочные антишаблоны
Anti-Pattern # 1
Проверка строк на ноль или пустоту
//Bad
if( myString == null || myString == "" )
OR
if( myString == null || myString.Length == 0 )
//Good
string.IsNullOrEmpty(myString)
Анти-шаблон № 2 (только для .NET 4.0)
Проверка строк на наличие нуля, пустого места или пробела
//Bad
if( myString == null || myString == "" || myString.Trim() == "")
//Good
string.IsNullOrWhiteSpace(myString)