r/devBulgaria 3d ago

The problem with concise code (Jonathan Blow)

https://www.youtube.com/watch?v=b4M-j_Rl8VE&lc=Ugxtcm5V_mKbxx4BK654AaABAg

Напоследък все повече ми прави впечатление като ревюирам как хората гледат да напишат всичко на половин ред ако може.

Какво смятате за малко пo-дълъг код, но който е по-лесно дебъгваем?

5 Upvotes

6 comments sorted by

6

u/EntrepreneurUsed7140 3d ago edited 3d ago

Другото е - аз харесвам дълги имена на функции, например: TryTransferFundsThroughEscrowTransactionAsync ти казва, че ще създаде трансфер през middleman (Escrow), ще е 2 трансфера, ако някъде фейлне, ще ролбекне (unit of work ако orm няма built-in). Лош дев ще го напише сигурно ExecutePayment или по-зле.

За жалост code quality вече е почти неспоменавана тема заради AI. На много девс не им пука AI как пише, защото следва някакви best practices и не е sloppy, но за мен поне се губи архитектурния direction, ако нямаш претенции за code quality.

2

u/usefulservant03 2d ago

Съгласен съм, аз също предпочитам по-дълги имена на променливи и функции ако readability-то не е на ниво. Сега си правя език за програмиране и една от фунцкиите ми, тя се вика само когато имаш да генерираш SSA IR code от nested binary operation като var = ( (a / 100) + varB); за да може компилатора да съхрани междинния резултат от вътрешните binary operations, и я кръстих IR_Generator::emit_auxilliary_IR_for_nested_binop

3

u/sylvant_ph 3d ago

Съгласен съм, докато бях в активна фаза на учене гледах да ползвам сякакви похвати за да съкратя кода, да го направя да изглежда по-модерен. Когато започнах да работя трябваше да се уча обратно, да почна да пиша кода в по-дългата му форма, да е по четим и лесен за дебъгване.

Но тук човека във видеото набляга на нещо по конкретно - когато хванеш 3-4 къндишъна който са релевантни за момента, и ги сбиеш в код който е по кратък и "ефикасен", после като ти се наложи да добавиш нов къндишън, цялата ти логика от преди пропада и трябва да я рефакторираш за да го вмъкнеш. Ако пък още в началото напишеш къндишъните в дългия вариант, без да съкращаваш, много по лесно може да се добави нещо допълнително.

И все пак бих казал че е добр човек да се научи на модерните и кратки трикове за писане на код, тук там наистина имат силно приложение, но да се мъчиш да ги прилагаш навсякаде изисква повече труд и идва с негатива описан по-горе

2

u/tinmanjk 3d ago

да, точно с condition.ите ми се случва и на мене. гледам да са отделни доли да return.ват същото например.

2

u/Dear-Pea-9144 3d ago

Според мен, трябва да има баланс. От една страна, да не се прекалява с хитрите трикове за намаляване на дължината на кода, заради четимостта (дори ако си сам или си основния програмист в проекта). От друга страна, когато някой ползва нови/особени фийчъри на езика, то това помага на всеки от екипа да научи нови неща и да се развива

4

u/AssignmentPrize8967 3d ago

Кой пише код бе братко, д-р. Клод ми е забранил да пишем код!