Все добре поки добре, коли погано, тоді суд та арбітраж.

Такі випадки треба робити публічними. Автору респект.

Як видно по коментам стаття реалістична, бо видно що герої себе побачили

Тобто, так, ви для цього дали права Jenkinsʼу щось комітити. І він на коміт розробника робить свій коміт з наступним білдом. Рекурсія — див. Рекурсія.
Дякую, більш питань нема.

Те, що я написав, то написав я.
А те що Ви подумали, то подумали Ви :)

Вибачте мені, але я трошки розумніший ніж Ви допускаєте :)

Річ у тім, що Ваше припущення про додавання тригеру на коміт розробника є хибним. Тому Ви зарано подякували :)

Тригер на форматування коду вішається на гілку спринта, коли робота девелопера прийнята і до неї не має зауважень, тобто є реальна причина заливати новий білд в ТестФлайт.

Вас правильно питали — Дженкінс комітить нову версію, чи як?
При нормальних налаштуваннях він не може цього робити, це зона компетенції SCM (Git чи що там буде).

Ще раз повторюю:
для мене важливий комфорт розробника, тому я переконаний, що розробник не повинен на своїй стороні робити ту роботу, яку можна виконати скриптом. Тим більше, що у клієнта можуть бути свої вимоги до оформлення коду — через це сперечатись з девелопером — вважаю тупізмом.

Тому, за зайвий рядок я нікого не задзьобую, бо це можна прибрати скриптом на Дженкінсі, бо коли збирається новий білд, скрипт на Дженкісні все рівно робить коміт в репозиторій з збільшеним номером білду, тому форматнути код у потрібний формат — то не питання для ClangFormat :)

нам подобається так :)

як кажуть: «У кожного Додіка своя методика».

Сперечатись в команді стосовно форматування коду — то дурне ІМХО.

Всі (в моїх командах) розуміють, що є (якщо є) вимога клієнта стосовно стилю форматування коду (LLVM, Google , Chromium, Mozilla, WebKit). Тому всім ясно, що код буде переформатовано Дженкінсом.

Тому з хуками на клієнті ніхто не грається :)

саме про це я і пишу :)

все рівно дженкінс збільшує номер білда, от хай ще форматне код.

В серьезных проэктах шифрованием паролей должен заниматься выделенный инженер который знает как это делать правильно.

Золоті слова!!!
Саме так у мене було на всіх проектах де вимагали захисту.

як раз змерджили — саме у цьому весь цимес!

Ок, розглянемо в цьому випадку продукт Firebase від відомого гіганта Google.

Є файний репозиторій з охайним кодом:
github.com/firebase/quickstart-ios

Але от незадача не було конвертовано код для Swift 4.2
Swift 4.2 було релізнуто 17 вересня swift.org/blog/swift-4-2-released але за 2,5 місяці до 30 листопада так ніхто і не спромігся оновити приклади для швидкого старту.

В силу душевної доброти я зробив цю роботу
github.com/...​e/quickstart-ios/pull/590
і що ми бачимо?

github.com/...​90#issuecomment-443352902

«This shouldn’t be merged yet. Our test infra doesn’t support Xcode 10 or Swift 4.2. There is an update I can push which checks for swift version and works for both 4.2 and 4. I’ve been holding off on it to move to 4.2 straight when our infra is updated. I should’ve commented earlier.»

За 2, 5 місяці так ніхто не піклувався про оновлення інфраструктури для нової версії свіфта!!!

Я був дуже здивований таким. Думав чим же вони таким, більш важливим займалися?

А тепер я точно знаю.

Фони код форматували, щоб він був охайним :)

Володя, що скажете про колег з сусіднього офісу?
Шіт хепенс віз евріван?

Колись я теж був таким категоричним ;)
Приколупуватись до девів стосовно форматування коду, коли це можна зробити скриптом , як мінімум тупо.

Є більш головні речі.
Звичайно якби це був Гугл, то мабуть така вимога є прийнятною, а для команд до 20 людей це перебор

>It’d be set by the caller before pushing this controller on the stack.

я виходив з того, що апп флоу відповідає вимозі:
до кожного екрану один можливий шлях.

Тому я переконаний, що попередній вьюконтролер буде такого типу як мені треба.

В іншому випадку, зробив би аналогічно Вашому варіанту через передачу параметром вьюконтролера.

Додам, щоб не правити пост:
мені біло ліньки налаштовувати дженкінс з усіма бантиками для тестового.

Мій підхід до тестових такий як ціна таксі:
дешево — ланос чи бляха
дорого — подадуть мерс чи іншу свіженьку машину.

Так і тут за 2500 викладатись як на 3500 — то себе не поважати.
Компроміси мають бути з двох сторін.

А тут получилось, що я повинен дешевше працювати, а вимоги до якості залишили попередніми.
Нема дурних :)
Яка риба — така юшка.

Не важно форматируют люди руками, скриптами, или у них триггер на pre-commit или post-save. Важно что в репозиторий код попадает в аккуратном виде.

До створення цього топіку якось не переймався цим питанням.

Раніше я вважав, що лише код для клієнта — 100% треба віддавати охайним.

Те що для себе чи в процесі — можна залишати як хочеться.
Розумію, що це не вірно.

Наразі багато зауважень — можна вводити як внутрішній стандарт.

Мені дійсно дуже цікаво побачити саме Ваш варіант.
Якщо ми не можемо використати стек вьюконтролерів, то має існувати інше рішення.

Треба трошки більше, з отриманням значення для змінної dueDateDelegate

Щоб вже було по дорослому.

Звичайно дуже жаль, що такий хай піднявся через таку дрібницю.

Не тільки у мене, але і у тих кому я показував цей топік склалося враження, що люди руками форматують :)

Стиль написання коду то не тільки переноси — то структурування насамперед. Тобто, то, що ти пишеш, повинно мати якийсь спільний підхід. Якщо використовуєш якісь поширені назви — то людина, яка потім буде переглядати код, очикуватиме використання коду згідно з назвою. Лінт це, нажаль, не перевірить.

Питання переносів та форматування вирішується банальним прогоном скрипта. Дуже прикро читати, що така дрібниця завадила багатьом дивитись далі.

Назви то питання 50/50: згоден, що якісь треба поправити, але не всі.

На приклади немає часу.

Отак завжди.

Шум підіймається, а як написати який стандарт вимог до оформлення коду треба використовувати, то друзьки :(

Тут вже є комент від люини з личною «архітектор», який сам признався що програмувати не вміє.

Тому приклад коду Вам дасть 100 очків вперед.

Може хтось Ваш підхід покритикує і ми побачимо нарешті істину :)

Я думаю что примеры кода вам в первую очередь не показывают потому что у вас в профиле много лет опыта разработки и есть ожидание что такому человеку достаточно подсказать куда смотреть, а не разбирать вопросы реализации по кубикам.

А я от чомусь думаю, що у критиків кишка тонка :)

Багато чую, що все погано, але як тільки просиш показати як правильно — всі стають такими загадковими... і зливаються :(

Хай буде на «ти», це не проблема, відпрацював 18 років в корпоративному секторі, то вже звичка :)

Насправді питання в тому, що є дійсно логіні речі. Мабуть сам бачив, деякі я визнав.

Стиль написання коду — то не проблема, воно вирішиться або обов«язковим прогоном скриптами для вирівнювання, переносів, тощо.
Ще щось вирішиться лінтом.

Питання в іншому: навіть тут є приклад, коли одна команда не хоче (не розуміє) роботу іншої команди.

Олексій Озюн (? вибачаюся якщо неправильно написав) так і не відповів на моє зауваження про забитий лог помилкою 401. Мабуть девопс особливо цьому не зрадіє, що перевірка мережі у нього виглядає як спроба втурчання.

Але найбільша проблема, як на мій погляд це тупо критика без прикладу як треба.

Ті, ліди які мене вчили, завжди показували як треба робити правильно. Така критика є продуктивною.

А таку критику як тут було 90% — ну озвучили проблему. Добре. Можеш показати як треба? Ні? Ну тоді мовчи будь ласка :) <- можливо грубо, але хоч час не марнується на «пойди туда незнаю куда, принеси то, не знаю что».

Отаке.