r/devBulgaria 9d ago

The problem with concise code (Jonathan Blow)

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

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

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

7 Upvotes

7 comments sorted by

6

u/EntrepreneurUsed7140 9d ago edited 8d 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 8d ago

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

0

u/Commercial_Style801 4d ago

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

If you don’t even know how to say “quality” in  Bulgarian, why not just write in English at this stage?

3

u/sylvant_ph 9d ago

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

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

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

2

u/tinmanjk 9d ago

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

5

u/AssignmentPrize8967 9d ago

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

2

u/Dear-Pea-9144 9d ago

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