Инициализация двойной скобки создает анонимный класс, полученный из указанного класса (внешние фигурные скобки external ) и предоставляет блок инициализации внутри этого класса (скобки inner ). например,
new ArrayList<Integer>() {{
add(1);
add(2);
}};
Обратите внимание, что эффект от использования этой инициализации двойной скобки заключается в том, что вы создаете анонимные внутренние классы. Созданный класс имеет неявный указатель this
к окружающему внешнему классу. Хотя обычно это не проблема, это может вызвать горе в некоторых обстоятельствах, например. при сборке или сборе мусора, и это стоит знать об этом.
tsql начинают & закончите..., это является раздражающим...
Относится к нескольким языкам:
Чувствительность к регистру - кто бы ни идея, была этим?! (И люди, которые используют SeveralWordsThatMeanSomething, а также severalwordsthatmeansomething для различных значений, должны быть застрелены :)
Индексация массива, запускающаяся от 0. Я происхожу из среды Фортрана, так, чтобы была другая причина, но в индексации массива математики всегда запускается с 1, таким образом, она имеет тенденцию создавать много головных болей (expecially при отладке) при реализации большей модели.
Точки с запятой - просто выбрасывают в коде. Если Вы - тщательное написание кода (Фортран, Python...) Вам не нужны они. Если Вы не, они не собираются сохранять Вас.
Фигурные скобки - видят 3.
p.s. Все Вы там. Не рассердиться. Если Вам не нравится ответ, Вы не должны были спрашивать.
У меня есть практический с лет кода revewing и отладки кода других людей. Я удалил бы (из всех языков) способность сгруппировать логические операции в условном операторе. Это прибывает из определенной жалобы на операцию И, например,
if (a and b)
{
do something
}
существует четыре случая, три из которых не были обработаны. Программист, возможно, рассмотрел все 4 случая и сознательно принял решение записать коду этот путь, но у нас нет признака, который имеет место, если они не прокомментировали код - и обычно они не делают.
Это может быть более подробным, но следующее однозначно...
if (a)
{
if (b)
{
do something
}
else
{
what about this case?
}
}
else
{
if (b)
{
what about this case?
}
else
{
do something else
}
}
Как плохое развитие человека год спустя, по крайней мере, я буду знать точно, что, как предполагается, продолжается.
I got one.
I have a grudge against all overly strict static typed languages.
I thought C# was awesome until I started being forced to write code like this:
void event...(object sender,EventArgs e){
int t=(int)(decimal)(MyControl.Value); //Value is an object which is actually a decimal to be converted into an int
}
Oh, and attributes are fugly. Could Microsoft seriously not think of anything uglier than [MyAttribute(Argument)] void function...
Seriously. wtf? Don't even get me started on XAML markup..
I can't take Python seriously because of the whitespace issue..
At times I have trouble taking Ruby seriously because
a) I taught myself from Why's Poignant Guide
b) Identifier type is determined by case in some instances. I've grown past this though cause it's sensible and more clean than a const
keyword. Now in every language when I make a constant it's uppercase.
Oh and I also hate the
if(a)
b();
syntax. You have no idea how many times I've just done
if(a)
b();
c();
by accident with code written like that.. Actually it can be worse with
if(a)
b(); c();
The only place it should ever be able to be used is
if(a){ ....
}else if(b){ ...
Ненавижу, что в Python я никогда не знаю, является ли что-то методом объекта или какой-то случайной функцией, плавающей вокруг (см. встроенные функции ). Такое ощущение, что они начали делать язык объектно-ориентированным, но потом пошли на спад. Для меня более разумно, чтобы такие функции были методами какого-то базового класса, например Object.
Я также ненавижу методы в стиле __ methodName __
, и если я действительно хочу до, я все еще могу получить доступ к частным материалам в классе извне класса.
Требование пробелов меня беспокоит; Я не хочу, чтобы разработчик языка заставлял меня кодировать определенным образом.
Мне не нравится идеал «один правильный способ сделать что-то», которого придерживается Python. Мне нужны варианты.