Opened 5 years ago
Closed 5 years ago
#6 closed ожидается проверка (задача сдана)
WW_1
Reported by: | Roman Venediktov | Owned by: | Sokolov Viacheslav |
---|---|---|---|
Component: | WW_make | Version: | 2.0 |
Keywords: | Cc: | Roman Venediktov |
Description
Change History (5)
comment:1 Changed 5 years ago by
comment:2 Changed 5 years ago by
Type: | ожидается проверка → ожидаются исправления |
---|
comment:4 Changed 5 years ago by
Cc: | Roman Venediktov added |
---|---|
Type: | ожидаются исправления → ожидается проверка |
Version: | 1.0 → 2.0 |
comment:5 Changed 5 years ago by
Resolution: | → задача сдана |
---|---|
Status: | assigned → closed |
Note: See
TracTickets for help on using
tickets.
Резюме: по сути все верно, но есть несколько огрех разной степени важности. Они перечислены ниже (не по порядку важности).
0) Бинарные файлы, включая lab1, не стоит держать в репозитории (они занимают место, для них diff не имеет смысла, легко получаются с помощью запуска компилятора).
1) В текущем состоянии сборка не работает
2) стандартная конвенция состоит в том, что цель называется
make clean
3) можно разбить компиляцию исполняемого файла на две цели: создание объектного файла main.o и последующую компоновку всех объектных файлов в исполняемый
4) в таком случа стоит сменить именование с runMain (это не очень хорошее название, потому что можно более точно назвать происходящий процесс) на, например, linkMain
И то, что не играет роли в этом задании, но будет играть значение дальше:
в файле
util.c
имеется неоднородность стиля кода (расстановка отступов до / после фигурных скобок; заключение очередного scope в фигурные скобки). Кроме того, я бы рекомендовал придерживаться стиля кода, в котором фигурные скобки ставятся на каждый возникающий scope. Да, кода становится чуть-чуть больше, но есть много других преимуществ (труднее ошибиться; проще портировать код; проще читать; .....)