- 01
- 02
- 03
- 04
- 05
- 06
- 07
- 08
- 09
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
class A
{
public:
int Left;
int Top;
int Right;
int Bottom;
public:
A ()
{
Left = Top = Right = Bottom = 10;
}
A (int L, int T, int R, int B)
{
L = Left;
T = Top;
R = Right;
B = Bottom;
}
};
Ну, возможно название класса не очень. Это повод считать код говнокодом?
Его целью может быть только введение пары-тройки ключевых слов, при этом не порождая лишних вопросов со стороны учащихся.
Это как школьная, университетская и институтская физики. Три учреждения -- три разных науки =]
Тоже и с программированием. Сначала познакомиться с классом как новой основной идей, потом с подробностями.
Если целью данного кода было показать ключевое слово class и пример нового уровня организации программы, то данный пример свою задачу выполнил.
А может быть это пример перегруженного конструктора?
Учебный пример -- это учебный пример.
Даже пример из "умной книжки" никогда не является "производственным решением", что говорить о студенческой методичке.
Я категорически против того, чтобы размещать ради "ржача" учебные примеры и студ. лабы.
А еще задачу, как не нужно писать конструкторы :-)
Не слишком ли много задач для одного учебного кода? ;-)
Я представляю себе, что такое учить людей.
Если с самого начала нашарашить класс с шаблонными параметрами, отделением реализации, закрытым наследованием обязательной реализации, с размещением в памяти и прочими заморочками, то у студента вспухнет голова... Он ничего не запомнит и не поймёт.
Название -- это, конечно, вещь важная, но вспомните математику. Вам для примера какие буквы писали? a,b,c x,y,z Когда будут свои проекты делать студенты, то им и объяснят, что программа не читается, что в ней сложно разобраться и ошибки подчеркнут студенту на его же программе.
Всё, что нужно -- это пояснить перед примером, что он содержит ошибки и не является примером, применимым в реальных условиях.
Вы не встречали в книжках по программированию сноски, поясняющие, что конкретные примеры могут быть улучшены или даже исправлены?
(j/k)
Может быть стоит делать относительно более правильные примеры, но очень простые. Но я бы не стал обращать внимание на название, когда что-то такое объясняется к названию не относящееся. Я бы скорее назвал класс __exL1_subTwo__ или что-нибудь ещё более запутанное, чтобы показать, что название сейчас роли не играет. Всё равно в первой же лабе всплывёт читабельность программы...
К слову о названиях. (далее юмор)
У меня в одном проекте был базовый тип исключенй (он и сейчас есть) sException. Только я понимал, что это исключения проекта S, остальным чудилось что-то другое (и это не строковое исключение). =]
(j/k)
И не нужно обращать на это внимание. Просто нужно сделать правильно, как-будто это само сабой разумеющееся.
(j/k)
p.s.: Классная у тебя подпись. Что-бы это значало?
(j/c) = just curious Просто интересно.
Например:
Guest, а какой у тебя рост? (j/c) Вопрос совершенно без определённой цели, просто интересно.
Всякие там rotfl lol (rolling over the floor laughting / laughing out loud) оттуда же.
Ещё бывают экзотические акронимы:
CYFTLT
WAO
T = Top;
R = Right;
B = Bottom;"
тут вообще-то надо наоборот. но это конечно же мелочи...
Точно! Деловое замечание =]
B = Bottom;
R = Right;
T = Top;
L = Left;
MagicNumbers это тоже опечатка?
Посмотрите на тело конструктора, который принимает четыре инта, он не класс инициализирует, а эти 4 инта.