<bgdev />free

Вход Регистрация

Празни редове като разграничители
0

0 1 2 3
#8596 (ツ) Унуфри
Създадено на 07.09.2020, видяно: 1274 пъти.

Обичате ли да четете метод, в който рядко има по някой и нов празен ред за разграничител? Може би широкоекранните монитори доведоха до това хората да сбиват колкото се може повече за да не скролират и да си пазят девелъпърите пръстчетата за да бият чикии.

#8606 (ツ) Courvoisier
Създадено на 07.09.2020, видяно: 1261 пъти.
Унуфри

Обичате ли да четете метод, в който рядко има по някой и нов празен ред за разграничител? Може би широкоекранните монитори доведоха до това хората да сбиват колкото се може повече за да не скролират и да си пазят девелъпърите пръстчетата за да бият чикии.

Да мрът такива

#8607 (ツ) Евлампи
Създадено на 07.09.2020, видяно: 1256 пъти.

Тия неща са като религиите. Винаги има повече от една всяка от които твърди че е истинската :)

Забавното е че това няма как да бъде решено веднъж и завинаги понеже визуалното форматиране/представяне носи информация или се предполага че улеснява някакъв аспект от работата с кода но различните ъгли от които се гледа и различните хора предполагат различни форматирания/представяния които са в конфликт. Примерно ако гледаме некъв code base от десет километра оптималното представяне е едно, ако ровичкаме в имплементацията на неква функция е друго, ако гледаме през очилата на организация като файлова система е трето, йерархията на класовете пък е четвърто и така

#8608 (ツ) relax4o
Създадено на 07.09.2020, видяно: 1245 пъти.
Унуфри

Обичате ли да четете метод, в който рядко има по някой и нов празен ред за разграничител? Може би широкоекранните монитори доведоха до това хората да сбиват колкото се може повече за да не скролират и да си пазят девелъпърите пръстчетата за да бият чикии.

Мразя. Въобще не ми помага с четенето на код, ами точно обратното, затруднява го. Като книга без запетаи и параграфи.

Но всеки е различен - очевидно, предвид, че има хора, които пишат така.

Особено пък като започнат да слагат едноредови if стейтмънти

if (bla-blah) continue;

който е плътно заобиколен от още код. Аз да не чета буква по буква, да го ева...

#8611 (ツ) Унуфри
Създадено на 07.09.2020, видяно: 1240 пъти.
relax4o
Унуфри

Обичате ли да четете метод, в който рядко има по някой и нов празен ред за разграничител? Може би широкоекранните монитори доведоха до това хората да сбиват колкото се може повече за да не скролират и да си пазят девелъпърите пръстчетата за да бият чикии.

Мразя. Въобще не ми помага с четенето на код, ами точно обратното, затруднява го. Като книга без запетаи и параграфи.

Но всеки е различен - очевидно, предвид, че има хора, които пишат така.

Особено пък като започнат да слагат едноредови if стейтмънти

if (bla-blah) continue;

който е плътно заобиколен от още код. Аз да не чета буква по буква, да го ева...

PR ми беше върнат точно защото не пиша едноредови оператори, слагам нови редове и също ламбда оператор => трябвало да е последен след сигнатура, а не на нов ред. Диктатура по-голяма и от тази на комунист, по-инатлива и от Рабин. Не видях смисъл да се боря с праведните и умно красивите, но исках да направя и бърз реалити чек.

#8617 (ツ) relax4o
Създадено на 07.09.2020, видяно: 1231 пъти.
Унуфри
relax4o
Унуфри

Обичате ли да четете метод, в който рядко има по някой и нов празен ред за разграничител? Може би широкоекранните монитори доведоха до това хората да сбиват колкото се може повече за да не скролират и да си пазят девелъпърите пръстчетата за да бият чикии.

Мразя. Въобще не ми помага с четенето на код, ами точно обратното, затруднява го. Като книга без запетаи и параграфи.

Но всеки е различен - очевидно, предвид, че има хора, които пишат така.

Особено пък като започнат да слагат едноредови if стейтмънти

if (bla-blah) continue;

който е плътно заобиколен от още код. Аз да не чета буква по буква, да го ева...

PR ми беше върнат точно защото не пиша едноредови оператори, слагам нови редове и също ламбда оператор => трябвало да е последен след сигнатура, а не на нов ред. Диктатура по-голяма и от тази на комунист, по-инатлива и от Рабин. Не видях смисъл да се боря с праведните и умно красивите, но исках да направя и бърз реалити чек.

Нямам толкова проблем с едноредов стейтмънт, ако преди и след него има по ред разграничение. Иначе докато чета кода, ако всичко е наблъскано едно в друго, highlights и прочие от IDE-то не ми помагат да ги разгранича.

Като учителката ми по електронни компоненти в гимназията "като отидете в университета ще се научите да четете по диагонал", че и аз така. С просто око не се ли вижда - проблем. :D

#8627 (ツ) |
Създадено на 07.09.2020, видяно: 1223 пъти.
Унуфри

Обичате ли да четете метод, в който рядко има по някой и нов празен ред за разграничител? Може би широкоекранните монитори доведоха до това хората да сбиват колкото се може повече за да не скролират и да си пазят девелъпърите пръстчетата за да бият чикии.

Кодът е проза и трябва да се спазват същите правила като когато се пише есе. Все пак кода не се пише за компютъра (иначе всички щяхме да пишем на асемблер), а за програмиста.

#8641 (ツ) relax4o
Създадено на 07.09.2020, видяно: 1209 пъти.
|
Унуфри

Обичате ли да четете метод, в който рядко има по някой и нов празен ред за разграничител? Може би широкоекранните монитори доведоха до това хората да сбиват колкото се може повече за да не скролират и да си пазят девелъпърите пръстчетата за да бият чикии.

Кодът е проза и трябва да се спазват същите правила като когато се пише есе. Все пак кода не се пише за компютъра (иначе всички щяхме да пишем на асемблер), а за програмиста.

Някои интересно защо, но просто не го разбират това. Сбиват го все едно е минифициран javascript, само и само файловете да са по-малки по размер и да се зареждат по-бързо при компилиране - WTF.

#8647 (ツ) johnfound
Последно редактирано на 07.09.2020 от johnfound, видяно: 1204 пъти.
|

Кодът е проза и трябва да се спазват същите правила като когато се пише есе. Все пак кода не се пише за компютъра (иначе всички щяхме да пишем на асемблер), а за програмиста.

Точно асемблерът е предназначен за четене от хора. Разбира се не говоря за инлайн-асемблерът в програма на език от високо ниво.

Достатъчно е да погледнеш кода на реален проект на асемблер (например на AsmBB) за да се убедиш, че добре написания асемблерски код е съвсем четлив, даже за хора като тебе, които не знаят езика.

А по темата - аз оставям празни редове там, където това повишава четливостта и не оставям редове там, където това намалява четливостта.

#8651 (ツ) |
Създадено на 07.09.2020, видяно: 1198 пъти.
johnfound
|

Кодът е проза и трябва да се спазват същите правила като когато се пише есе. Все пак кода не се пише за компютъра (иначе всички щяхме да пишем на асемблер), а за програмиста.

Точно асемблерът е предназначен за четене от хора. Разбира се не говоря за инлайн-асемблерът в програма на език от високо ниво.

Достатъчно е да погледнеш кода на реален проект на асемблер (например на AsmBB) за да се убедиш, че добре написания асемблерски код е съвсем четлив, даже за хора като тебе, които не знаят езика.

А по темата - аз оставям празни редове там, където това повишава четливостта и не оставям редове там, където това намалява четливостта.

Поназнайвам аз асемблер, все първия x86 който съм използвал е Правец 16. Дори в един момент, в пристъп на умопомрачение бях писал еквивалент на xcopy на асемблер.

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

#8655 (ツ) johnfound
Създадено на 07.09.2020, видяно: 1190 пъти.
|

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

Явно страдаш от комплекс за малоценност. Компилаторите се справят добре, но не и по-добре.

И даже повече, може формално да се докаже, че компилаторът по принцип може да създаде само по-лош или еквивалентен на код, създаден от човек.

#8658 (ツ) 40oz
Създадено на 07.09.2020, видяно: 1183 пъти.
johnfound

И даже повече, може формално да се докаже, че компилаторът по принцип може да създаде само по-лош или еквивалентен на код, създаден от човек.

Това ми е много интересно как се доказва

#8659 (ツ) |
Последно редактирано на 07.09.2020 от |, видяно: 1183 пъти.
johnfound
|

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

Явно страдаш от комплекс за малоценност. Компилаторите се справят добре, но не и по-добре.

И даже повече, може формално да се докаже, че компилаторът по принцип може да създаде само по-лош или еквивалентен на код, създаден от човек.

Правиш ли loop unrolling? Слагаш ли prefetch инструкциите на правилното място? Местиш ли независимите инструкции за да намалиш register pressure и да помогнеш да процесора да прави register renaming?

Поне това се сещам в момента, сигурно има десетки други неща, които съм забравил.

#8664 (ツ) johnfound
Създадено на 07.09.2020, видяно: 1168 пъти.
40oz
johnfound

И даже повече, може формално да се докаже, че компилаторът по принцип може да създаде само по-лош или еквивалентен на код, създаден от човек.

Това ми е много интересно как се доказва

Елементарно се доказва.

1. Ако човек и компилатор решават една и съща задача и решението на човека е по-добро, то теоремата е доказана.

2. Ако решението на човека е по-лошо, то той може да дизасемблира кода на компилатора, да го анализира, усъвършенства и използва. Ако успее, неговият код ще е по-добър. Ако не успее, неговият код ще е еквивалентен.

3. Компилаторът не може да анализира кода на човека от т.1

Теоремата е доказана.

#8666 (ツ) Stilgar
Създадено на 07.09.2020, видяно: 1162 пъти.

Без да чета другото ще кажа че да не слагаш празен ред след } за блок е престъпление срещу колегите и себе си.

#8667 (ツ) code2
Създадено на 07.09.2020, видяно: 1158 пъти.
johnfound
40oz
johnfound

И даже повече, може формално да се докаже, че компилаторът по принцип може да създаде само по-лош или еквивалентен на код, създаден от човек.

Това ми е много интересно как се доказва

Елементарно се доказва.

1. Ако човек и компилатор решават една и съща задача и решението на човека е по-добро, то теоремата е доказана.

2. Ако решението на човека е по-лошо, то той може да дизасемблира кода на компилатора, да го анализира, усъвършенства и използва. Ако успее, неговият код ще е по-добър. Ако не успее, неговият код ще е еквивалентен.

3. Компилаторът не може да анализира кода на човека от т.1

Теоремата е доказана.

В точка 2 последното изречение "Ако не успее, неговият код ще е еквивалентен". Ако не успее, то трябва ли дизасемблираният код да се счита за негов?

#8668 (ツ) ФейкПрофил
Последно редактирано на 07.09.2020 от ФейкПрофил, видяно: 1157 пъти.

Да слагаш { на нов ред също е престъпление срещо човечеството. Почти толкова лошо, колкото да ползваш табове.

#8669 (ツ) |
Създадено на 07.09.2020, видяно: 1157 пъти.
johnfound
40oz
johnfound

И даже повече, може формално да се докаже, че компилаторът по принцип може да създаде само по-лош или еквивалентен на код, създаден от човек.

Това ми е много интересно как се доказва

Елементарно се доказва.

1. Ако човек и компилатор решават една и съща задача и решението на човека е по-добро, то теоремата е доказана.

2. Ако решението на човека е по-лошо, то той може да дизасемблира кода на компилатора, да го анализира, усъвършенства и използва. Ако успее, неговият код ще е по-добър. Ако не успее, неговият код ще е еквивалентен.

3. Компилаторът не може да анализира кода на човека от т.1

Теоремата е доказана.

Приложи тези три точки за игра на шахмат на компютър и човек и може би ще схванеш къде грешиш. :) Да, човек може да анализира играта на компютър. Това ще му помогне ли следващия път? :)

#8670 (ツ) Golden Gega
Създадено на 07.09.2020, видяно: 1155 пъти.
johnfound
40oz
johnfound

И даже повече, може формално да се докаже, че компилаторът по принцип може да създаде само по-лош или еквивалентен на код, създаден от човек.

Това ми е много интересно как се доказва

Елементарно се доказва.

1. Ако човек и компилатор решават една и съща задача и решението на човека е по-добро, то теоремата е доказана.

2. Ако решението на човека е по-лошо, то той може да дизасемблира кода на компилатора, да го анализира, усъвършенства и използва. Ако успее, неговият код ще е по-добър. Ако не успее, неговият код ще е еквивалентен.

3. Компилаторът не може да анализира кода на човека от т.1

Теоремата е доказана.

Глупости на търкалета rofl Ако човека е некадърен въобще няма гаранция че ще успее да използва дизасемблирания код, особено в по-дълга задача, да не говорим че има шанс да го смотае още повече. Дори обаче да стигне дотам че да използва кода на компилатора, то тогава е решил задачата за повече време и пак губи.

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

Твърдението е разбито.

#8672 (ツ) ФейкПрофил
Създадено на 07.09.2020, видяно: 1151 пъти.
johnfound
40oz
johnfound

И даже повече, може формално да се докаже, че компилаторът по принцип може да създаде само по-лош или еквивалентен на код, създаден от човек.

Това ми е много интересно как се доказва

Елементарно се доказва.

1. Ако човек и компилатор решават една и съща задача и решението на човека е по-добро, то теоремата е доказана.

2. Ако решението на човека е по-лошо, то той може да дизасемблира кода на компилатора, да го анализира, усъвършенства и използва. Ако успее, неговият код ще е по-добър. Ако не успее, неговият код ще е еквивалентен.

3. Компилаторът не може да анализира кода на човека от т.1

Теоремата е доказана.

FastForward 100 години в бъдещето и наблюдаваме двама нърда, които спорят кой-пише по-добър код - човека или изкуствения интелект :)

0 1 2 3

Празни редове като разграничители
0

AsmBB v3.0 (check-in: a316dab8b98d07d9); SQLite v3.42.0 (check-in: 831d0fb2836b71c9);
©2016..2023 John Found; Licensed under EUPL. Powered by Assembly language Created with Fresh IDE