Дълго поддържани, неправилни допускания за програмиране [затворено]

Правя проучване на често срещани грешки и лоши предположения, направени от младши (и може би старши) софтуерни инженери.

Кое беше най-дългото ви предположение, което в крайна сметка беше коригирано?

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

Бъди честен; какво твърдо убеждение имахте и приблизително колко дълго поддържахте предположението? Може да става въпрос за алгоритъм, език, концепция за програмиране, тестване или нещо друго относно програмирането, езиците за програмиране или компютърните науки.


person Community    schedule 20.05.2009    source източник
comment
Може да се интересувате doi.acm.org/10.1145/1364782.1364795 doi.acm.org/10.1145/984458.984495 doi.acm.org/10.1145/1142031.1142053   -  person Simon Gibbs    schedule 20.05.2009


Отговори (195)


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

Четенето на блогове, Stack Overflow и книгите за програмиране винаги ме караха да чувствам, че съм зад кривата на нещата, които всички програмисти трябва да знаят интуитивно.

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

person Community    schedule 21.05.2009
comment
Толкова вярно! Това е проблемът на тази епоха. Информацията също е обезкуражаваща. Получих това разкритие преди няколко седмици, когато се почувствах като пълен губещ във всичко, което направих (не за първи път) по отношение на изследванията. Момчета, чиито статии се публикуват в IEEE Transactions, не е задължително да имат същите умения като момчета, които работят в Google, хвалят се в StackOverflow, са отлични професори или пишат страхотни блогове за програмиране. Разбира се, най-добрите момчета са експоненциално по-готини от нас, но те не знаят всичко, което вие знаете, което не знаете. Така че, останете хладни. - person jbasko; 21.05.2009
comment
Също така помага да се разбере, че тези блогъри също не пишат всичко от главата си. Добрите блогъри проучват своите теми и научават нови неща, докато пишат публикации. - person JohnFx; 21.05.2009
comment
Ежедневно съм обсебен от нещата, за които нямам време да чета и да науча. Това понякога ме оставя с ужасно чувство за вина. - person brad; 22.05.2009
comment
Знам как се чувстваш. Наистина се старая да съм в крак с тези неща, но все пак имам ежедневна работа! - person JohnFx; 22.05.2009
comment
URL адресът е обяснителен: liveintentionally.com/Too_Many_Choices.htm - person corlettk; 23.05.2009
comment
Напълно! Благодаря, че го изразихте така, почувствах се толкова отчужден, когато започнах да чета този сайт, мислейки си за дяволите, нищо не знам!. - person Alex; 23.05.2009
comment
Аз правя точно същото и никога не съм го осъзнавал... дълго време се чувствах твърде песимистично и скромно относно уменията си въз основа на феномена, описан по-горе... - person Konstantinos; 24.05.2009
comment
@Zilupe: Амин за това. Публикувал съм няколко доклада от международни конференции и списания. В очите на някои хора това звучеше готино. Докато не осъзнаете, че всъщност не са нужни много усилия, за да публикувате статия. Ние не сме гении. Ние сме като всички останали. Направихме грешки и публикуваме глупости. Е, с изключение на някои малцинствени групи от истински гении... - person Hao Wooi Lim; 25.05.2009
comment
Абсолютно съгласен!! От повечето разработчици, работещи по комерсиални проекти, се очаква да ги изпълнят срещу тежки срокове. Чудя се колко следват OO практики, насоки за добро кодиране, разработка, управлявана от тестове и т.н. Виждал съм много .NET проекти, които не следват подходяща многослойна архитектура главно поради времеви и ресурсни ограничения. - person Shaw; 25.05.2009
comment
о, добре, предполагам, че малко се отклоних от темата. Това, което исках да кажа, е, че не всички са гениални разработчици и затова, когато видите някой от SO да изтъква важността на TDD, OO, докато всички са напълно дадени с добри намерения, не се съжалявайте, че не сте достатъчно добър , защото не ги правиш. Всички работим при обстоятелствата, в които се намираме, и понякога не е възможно да следваме добрите практики. - person Shaw; 25.05.2009
comment
[...] Ефективно сравнявам знанията си с колективните знания на много хора. <<<< Точно!! - person hasen; 27.05.2009
comment
Може би това е нотката на вина/съжаление, която ни тласка да станем по-добри в занаята си. Предполагам, че в крайна сметка това е нещо добро. - person JohnFx; 27.05.2009
comment
+1 Добре, че прочетох това. Мислех, че съм единственият. - person Randell; 29.07.2009
comment
Това спаси мозъка ми от пържене. Напоследък си мисля повече за това, което не знам и как изглежда, че всички знаят всичко толкова перфектно, отколкото всъщност да науча нещо! Радвам се да видя, че не съм единственият! - person Michal Ciechan; 18.04.2010
comment
Човече, не бих могъл да прочета това в по-добър момент.. - person Jeriko; 23.05.2010
comment
Съгласен съм с публикуването на JohnFx. Въпреки това, FWITW @JohnFX... аз знам повече от теб ;-) - person user279521; 11.08.2010
comment
@user279521 - О, да? Колко пръста държа вдигнати? - person JohnFx; 11.10.2010
comment
@JohnFx 2 месеца по-късно..... +1 (по дяволите ти си бавен пич).... - person user279521; 11.10.2010

Че хората знаеха какво искат.

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

Редактиране: Съгласен съм с повечето коментари. Това не е технически отговор и може да не е това, което питащият е търсил. Не се отнася само за програмирането. Сигурен съм, че това също не е най-дълго поддържаното ми предположение, но беше най-поразителното нещо, което научих през 10-те кратки години, в които се занимавам с това. Сигурен съм, че беше чиста наивност от моя страна, но начинът, по който мозъкът ми е/беше свързан и преподаването и опитът, който имах преди да вляза в света на бизнеса, ме накараха да повярвам, че ще правя това, което отговорих; че ще мога да използвам код и компютри, за да разрешавам проблемите на хората.

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

Редактиране: Този отговор вече е уики на общността, за да успокои хората, разстроени от този отговор, като ми дава репутация.

person Community    schedule 20.05.2009
comment
Или да променят това, което искат, след като са видели това, което са искали преди. Хората обичат да променят мнението си. Знам, защото съм народ. - person J. Polfer; 20.05.2009
comment
Давахте им това, което поискаха, а не това, което искаха. - person Brent Baisley; 20.05.2009
comment
Защо скучните безспорни отговори без отговор се гласуват толкова много?! - person nes1983; 20.05.2009
comment
Искам да кажа, пич, това не е твърдение, което може да е грешно или невярно, не е наистина твърдение, по-скоро твоето възприятие се промени. Той не отговаря на условията на първоначалните въпроси и описва повече вашия все по-песимистичен поглед върху нежното същество, отколкото напредъка ви като учен. - person nes1983; 20.05.2009
comment
Еха. Звучи сякаш някой има нужда от прегръдка. - person bzlm; 21.05.2009
comment
@niko- това е добър отговор..дори аз го гласувах и моят отговор трябва да се конкурира ;) - person TStamper; 21.05.2009
comment
@Brent Baisley: Още по-лошо, вие им давате това, което смятате, че са поискали въз основа на това, което са поискали, а не на това, което са искали. - person Hao Wooi Lim; 21.05.2009
comment
Какво ви накара да направите това предположение на първо място? - person Daniel Daranas; 21.05.2009
comment
За да не бъдем педантични, но изглежда, че това, което установявате, е, че изграждането на системи е ИНТЕРАКТИВЕН процес. Идея, прототип (и понякога внедряване), кошче за боклук, нова идея... и т.н. Или можете да го видите като хората са глупави, което също е вярно... - person Dan Rosenstark; 21.05.2009
comment
Ето защо харесвам гъвкавото управление на проекти. - person Scoregraphic; 21.05.2009
comment
@Niko: Отговорът е ОК. Фактът, че той получи почти 400 представителя от него, е BS. - person gnovice; 21.05.2009
comment
От друга страна, някои хора знаят какво искат, но това е абсолютно безсмислено. Например, един от нашите клиенти познавам този човек и лично знам, че той има толкова пари, искаме да го подчертаем на нашата уеб страница, но не можем да съхраняваме никъде нищо, което показва това, можете ли да го направите? . Хммм. - person Kezzer; 21.05.2009
comment
Мисля, че можеш да имаш това, което искаш или което ти трябва, но не можеш да имаш и двете... обикновено. (от Simple Men на Хал Хартли) - person Daniel Daranas; 21.05.2009
comment
@Daniel Daranas: Звучи като принципа на неопределеността за софтуера... - person Treb; 22.05.2009
comment
Боже мой @ хората се оплакват, представителят на stackoverflow не е състезание. Гласувайте за, ако отговорът ви е харесал, не гласувайте против, защото завиждате, че не сте го публикували първи. - person Dmitri Farkov; 22.05.2009
comment
@All - изложи разсъжденията си и спря натрупването на повторения. Благодаря за коментарите, бях изненадан, че този отговор генерира това, което направи! - person Instantsoup; 22.05.2009
comment
Това определено заслужава да бъде най-високо гласуваният отговор. Идеята, че наивното питане на потребителите какво искат ще произведе най-добрия продукт, е широко разпространена и много, много погрешна. Особено важно е да имате предвид, когато създавате shrinkwrap или уеб софтуер: потребителите, които ви дават обратна връзка, са само част от общите ви потребители и това ще изкриви вашата гледна точка. - person Wedge; 22.05.2009
comment
Може би искам това да е отговорът с най-много гласове. Може би не го правя. Не съм сигурен. - person Daniel Daranas; 22.05.2009
comment
Любимото ми е, когато видите нещо нередно в това, което клиентът е поискал, и го посочите. Когато го изградя по този начин, той ще направи X, което съм почти сигурен, че не искате да прави. Те ви казват да го създадете така или иначе и след това 6 месеца по-късно изпадате в паника, когато изданието е отложено, защото прави X и трябва да бъде „поправено“. - person Jherico; 22.05.2009
comment
@Jherico това се нарича заявка за промяна в договора = $$$. - person Daniel Daranas; 22.05.2009
comment
Понякога клиентите ви карат да приложите нещо, само за да им помогнете да решат какво искат. В идеалния случай доказателството за концепцията трябва да го направи, но се случва много рядко. - person Sergiu; 22.05.2009

Че знам къде е проблемът с производителността без профилиране

person Community    schedule 20.05.2009
comment
Мисля, че това е причината преждевременната оптимизация да е толкова често срещана. - person Hao Wooi Lim; 21.05.2009
comment
+1 Уау, някой е включил отговор, който не е тривиален или извън темата. - person Mark Rogers; 21.05.2009
comment
Имам няколко таблетки, които трябва да помогнат с преждевременната оптимизация... - person AndyM; 28.08.2009

Че трябва да имам само една изходна точка от функция/метод.

person Community    schedule 20.05.2009
comment
Отлична реализация; излизайте толкова често, колкото е необходимо. Човек трябва да се спаси от функция веднага щом няма смисъл да продължава по-нататък в нея. Правейки това, можете да намалите сложността и да увеличите четливостта, като например избягвате дълбоко вложени условни изрази, когато те са предпоставки, необходими за правилното изпълнение на метода. В съвременните езици с управление на паметта и конструкции на ресурси като използване/накрая, продължаването до края на метода догматично няма смисъл. - person Triynko; 20.05.2009
comment
Между другото, кой го измисли? Това е като градска легенда за програмиране. - person brad; 22.05.2009
comment
Хората, които трябва да дебъгват кода на други хора, са тези, които са измислили това. - person gatorfax; 22.05.2009
comment
Ако вашият код е толкова дълбоко вложен, че не можете да опитате да направите една изходна точка, тогава преработете кода. Преместете неща в методи с имена, които описват какво се случва и т.н... Разбира се, че трябва да следвате всеки метод, за да разберете какво точно прави всеки метод, но поне можете да получите голямата картина, просто като погледнете кои методи се извикват, при какви условия. Тогава не можете да поставите много изходни точки, нали? Така че чрез всички ваши изходни точки вие карате някой да трябва напълно да реорганизира кода ви, така че да може да преработи тонове вложени условни изрази в отделни методи. - person DoctorFoo; 22.05.2009
comment
Моят учител по структури на данни преподаваше това. Винаги съм смятал, че е объркващо и ненужно, но неговите изпити се основаваха на това предположение. - person Edison Gustavo Muenz; 22.05.2009
comment
Мисля, че тази общоприета, но погрешна идея се основава на недоразумение. Когато излезете от функция, винаги трябва да се връщате към същата точка. Това беше важно правило в езици като BASIC, които не го налагаха: правилото означаваше, например, че трябва да използвате GOSUB вместо GOTO. В езици като C# или Java, които извикват методи, това е автоматично. Но тъй като е автоматичен, мисля, че се трансформира от логичната само една точка за връщане към безсмислената само една изходна точка. - person Ryan Lundy; 22.05.2009
comment
От езици като C, където трябва ръчно да освободите ресурси. Множеството изходни точки бяха добър шанс за изтичане на ресурси. IMO няма смисъл от това в езици с изключения, тъй като често вече не знаете вашите изходни точки или те са в средата на изявление. -- В тези езици всичко, което остава, е структура за четливост. - person peterchen; 28.05.2009
comment
Мисля, че това правило е измислено от хора, ориентирани към блок-схеми (като някои глупави инструктори в моя колеж :-P) - person mmx; 01.06.2009
comment
-1. Една единствена изходна точка е единственият разумен начин за налагане на постусловия. - person Adrian McCarthy; 04.06.2009
comment
@Adrian McCarthy - само ако използвате C. Повечето други езици имат нещо като try/finally, някои езици/платформи имат вградена поддръжка за постусловия. - person Daniel Earwicker; 31.07.2009
comment
Никога не съм имал проблем с множество изходи, стига да се използват отговорно. Използвайте ги или в горната част на функцията, за да върнете рано неочаквани параметри (обикновено null), или в оператор if/switch/try-catch в логиката. Само не ги крийте навсякъде. - person PeteT; 17.12.2009
comment
„връщане“, „продължаване“ и „изход“ са любимите ми ключови думи. - person Evan Plaice; 14.06.2010
comment
Хората често бъркат лошото програмиране с неподчиняването на правило. Така че те се опитват да наложат правила като една изходна точка в световен мащаб, защото смятат, че това ще премахне лошото програмиране. OEP има смисъл, когато имате нужда от вашия метод за извършване на почистване. В останалите 95% от случаите това води до отвратително влагане и по-малко четлив код. Всичко опира до използването на правилния инструмент за работата. За някои функции на някои езици OEP е много добра идея. - person Jason Williams; 12.07.2010
comment
@Adrian: Ако имате нещо достатъчно сложно, за да имате реални проблеми с ранно излизане, може би е най-добре да разделите функцията на две части, външна, която обработва ресурси и пред/след условия, и вътрешна който върши истинската работа и който може да използва ранно излизане, ако е необходимо. През повечето време обаче не се нуждаете от такъв вид сложност. - person Donal Fellows; 13.07.2010
comment
@Donal Fellows: Бих казал точно обратното. Ако откриете, че се нуждаете от множество изходни точки, вероятно не сте разложили правилно проблема. - person Adrian McCarthy; 13.07.2010
comment
@Adrian: Това звучи като един от тези аргументи, при които различните страни смятат, че другата е напълно грешна. - person Donal Fellows; 13.07.2010
comment
Ако имате нужда от множество изходни точки в нетривиален код, трябва да помислите за рефакторинг на вашата функция. - person Joe Zitzelberger; 05.01.2011

Че непрограмистите разбират за какво говоря.

person Community    schedule 20.05.2009
comment
разбирам/пука.. - person nickf; 20.05.2009
comment
Все още го имам на моменти... Мислех, че поне жена ми вече ще е започнала да разбира правилно :P - person workmad3; 21.05.2009
comment
О, скъпи, страхувам се, че може би тепърва ще науча това! - person thatismatt; 21.05.2009
comment
да, понякога забравям публиката си и в крайна сметка се озовавам с куп хора с празни погледи на лицата си, които се взират в мен, но е хубаво, когато хората проявяват интерес - person Petey B; 05.06.2009
comment
Това е най-голямото ми разочарование от професията. - person Andres Jaan Tack; 24.06.2010
comment
Все още се боря с това; сега поне разпознавам изцъкленото изражение на жена ми, когато говоря технологично! - person John Warlow; 12.07.2010
comment
Всъщност какво ще кажете за това, че програмистите разбират за какво говоря. - person AviD; 16.06.2011

Този софтуер без грешки беше възможен.

person Community    schedule 20.05.2009
comment
+1, въпреки че НАСА почти успя - person Patrick McDonald; 20.05.2009
comment
Да, но почти струва няколко милиона долара :) - person Jem; 20.05.2009
comment
Все още не е постигнато, но определено е възможно (стига да продължим да работим с детерминиран цифров хардуер). Ще трябва да започнем от нулата с нова, внимателно проектирана операционна система и хардуер без сериозни грешки в дизайна. - person Triynko; 20.05.2009
comment
Какво е детерминиран цифров хардуер? - person Liran Orevi; 20.05.2009
comment
За да бъдем малко по-конкретни, безплатният софтуер за грешки беше възможен при нормален бюджет - person Frank Farmer; 21.05.2009
comment
Никога няма да имате софтуер без грешки, а само софтуер, в който все още не са открити грешки. - person Mark Glorie; 21.05.2009
comment
+1 към Патрик, това е почти утопия, но мисля, че всеки знае, че това не е софтуер без грешки, а почти без грешки. - person dr. evil; 21.05.2009
comment
Не искам програма без грешки, не е забавна и ще намали процента на заетост на разработчика с 10! - person Nicolas Dorier; 21.05.2009
comment
Уау, получих -1 глас за този отговор. Хората наистина ли смятат, че е възможен софтуер без грешки? - person JaredPar; 21.05.2009
comment
@Triynko твоето възможно и възможното на @JaredPar не са едно и също. Теорията и практиката може да са едни и същи на теория, но са много различни на практика. - person wilhelmtell; 22.05.2009
comment
Зависи дали имате предвид алгоритмична коректност или „прави това, което потребителят иска да прави“. Първото със сигурност е възможно. - person Steven Evers; 22.05.2009
comment
@wilhelmtell: Теорията и практиката са различни само когато не знаеш какво означава теория. Хората изглежда го бъркат с предположения. @Jared: да, винаги съм си мислил, че ако мога просто да бъда по-умен, да се старая повече, да науча повече, ще мога да го направя. Това е същата причина, поради която създаваме толкова много закони, имаме толкова години образование, приемаме толкова много лекарства и т.н.: може би с малко повече контрол можем да направим всичко перфектно, нали? (Много извън темата?) - person Jay Bazuzi; 22.05.2009
comment
@JaredPar Виждал съм много приложения Hello World, които са НАПЪЛНО свободни от грешки =P Всъщност, много книги за програмиране, които взимам, съдържат този малък човек по един или друг начин и не мога да се сетя за такъв, който имаше бъг в него =P - person Joseph; 22.05.2009
comment
@Joseph, част от проблема е, че хората смятат, че програмите Hello World са без грешки. Те не са. Повечето не проверяват за грешки в printf например или отчитат други неуспешни опити за IO. - person JaredPar; 22.05.2009
comment
@JaredPar прав - най-тривиалният софтуер има грешки. Всеки нетривиален софтуер има грешки. Просто не е възможно да се пише интересен софтуер без грешки с днешните инструменти; и изглежда, че сме готини с това в по-голямата си част. Софтуерът наистина върши невероятна работа, като се има предвид колко сложен става. Дори прословутият офис изглежда винаги възстановява незапазените ми документи, ако го пресека :). Извървяхме дълъг път през това десетилетие в обработването по-добре на неизбежните грешки. - person Michael Haren; 23.05.2009
comment
Автопилотите със системи Autoland за самолети трябва да могат да извършват повече от 1 милион кацания без произшествие. Повечето използват три компютъра, работещи паралелно, 1 управлявайки самолета, 2 проверявайки първия за грешки. Това е почти толкова близо до липсата на грешки, колкото ще получите. За протокола работих върху тези системи, но не съм ги програмирал, - person Jim C; 30.05.2009
comment
Ще трябва да гласувам против това. Възможно е да имате софтуер без грешки и има непрекъснато развиваща се наука, за да се постигне това. Да се ​​уверите, че няма софтуер без грешки, е просто извинение, за да не ви пука. Това помага за стагнация на важна изследователска тема в софтуерното инженерство. - person Juliano; 04.06.2009
comment
Знам един - TeX. Има дори цена за всеки бъг afaik. - person Tobias Langner; 28.08.2009
comment
Тази C програма не съдържа ли грешки? void main() {} ;-) - person RussellH; 29.09.2009
comment
@RussellH, не. Не сте успели да посочите върната стойност и полученият процес ще върне произволна ненужна памет. - person JaredPar; 29.09.2009
comment
@JaredPar: Софтуерът без грешки е напълно възможен. Въпреки това изисква търпение и много квалифицирани програмисти, като и двата са дефицитни. Което прави възможен безплатен софтуер за грешки, но е малко вероятно. - person NotMe; 12.07.2010
comment
Софтуерът без грешки трябва да отчита ВСЕКИ случай. Включително лош дизайн и потребителски интерфейс, дефектни компоненти и да го доведете до крайност, тогава може би дори прекъсвания на захранването? - person Robin Day; 12.07.2010
comment
Все още не разбирам какво всъщност е бъг? :) - person THEn; 16.07.2010
comment
Моля, не тръгвайте да анализирате литературата за значението на думата възможно. Ние сме компютърни програмисти. Писането на софтуер без грешки просто не е възможно. :) - person Donotalo; 29.09.2010
comment
@JaredPar -- полученият процес ще върне произволна боклук памет. Това е функция, а не грешка. :-). - person RussellH; 01.12.2010

Тези частни членски променливи са частни за екземпляра, а не за класа.

person Community    schedule 20.05.2009
comment
Това е често срещано. Обикновено трябва да предоставя тестови случаи, преди хората да ми повярват. - person Bill the Lizard; 20.05.2009
comment
Някои хора смятат, че трябва да бъдат. Вижте „случай 4“ в gbracha.blogspot.com/ 2009/03/ - person Daniel James; 20.05.2009
comment
Поддържах това предположение до... току що. - person TheMissingLINQ; 20.05.2009
comment
Можете да направите това в Scala; private[this] val foo = 42 - person egaga; 20.05.2009
comment
Този е нов за мен! Въпреки че не мога да се сетя за случай, в който това би ми било полезно в миналото. - person ebrown; 20.05.2009
comment
@ebrown Обикновено го намирам за полезен само когато пиша метод equals(). - person Dave Webb; 20.05.2009
comment
Те са в Ruby. - person Mike Kucera; 21.05.2009
comment
Открих това наскоро, когато създавах функция за клониране. Бях изненадан, че работи. - person Meta-Knight; 21.05.2009
comment
Майк Кучера, благодаря, не знаех това за Руби. Още по-лошо, още не се е появило :) - person Dan Rosenstark; 21.05.2009
comment
Разбрах го след 3 или 4 години усилено програмиране - person Nicolas Dorier; 21.05.2009
comment
Това е толкова нормално за мен, че този отговор нямаше смисъл първите няколко пъти, когато го прочетох. Сега искам да науча Ruby, за да може да ме обърка по друг начин. :) - person jmucchiello; 21.05.2009
comment
VB6 използва значението само на екземпляр за частно. Всъщност няма обхват за „само този клас“. - person Craig Gidney; 22.05.2009
comment
Ново и за мен! Благодаря :) - person CloudyMusic; 22.05.2009
comment
Мисля, че мозъкът ми току-що се счупи... Трябва да отида да го поправя сега - person Joseph; 22.05.2009
comment
За момент си помислих, че тук става дума за стойности, а не за променливи, което ме накара да се зачудя как изобщо е работил кодът, който съм писал до момента. - person Jeremy Frey; 23.05.2009
comment
Зависи от езика. В C# това е правилно, но не съм сигурен, че е вярно за всеки език, който поддържа капсулиране. - person Krzysztof Kozmic; 27.05.2009
comment
За какво говориш? Някой има ли пример? :P - person kiewic; 19.06.2009
comment
@Kiewic Ако имате частна членска променлива, наречена myVar във вашия клас, можете да посочите other.myVar директно във вашия код, ако other е екземпляр на този клас. Бях предположил, че трябва да използвате other.getMyVar(), тъй като е лично, дори вътре в класа. - person Dave Webb; 19.06.2009
comment
@Dave Webb Сега всичко има смисъл, благодаря! - person kiewic; 23.06.2009
comment
Дискусия относно този отговор може да бъде намерена тук: stackoverflow.com/questions/1357496/ - person Moayad Mardini; 31.08.2009
comment
Никога не съм бил объркан от това. Как иначе бихте претоварили оператор за сравнение? - person Matt Brunell; 13.10.2009
comment
@Дейв Уеб, твоето неправилно предположение не трябва ли да бъде, че променливите частни членове са частни за екземпляра и класа. С други думи, мога да получа директен достъп до частна променлива на друг обект, ако този обект е от същия клас като мен. Объркан съм. - person Ash; 20.10.2009
comment
Научавам това и после го забравям ... и после го научавам и после го забравям ... - person cplotts; 23.10.2009
comment
Уау, това всъщност леко разтърси света ми. - person Finbarr; 17.06.2010
comment
@Mike Kucera: Това е все едно да кажеш, че никой не може да скочи 10 метра високо - Бог може. - person Vincent; 11.08.2010

Мислех, че статичното писане стои много неподвижно на клавиатурата ви.

person Community    schedule 20.05.2009
comment
Искрено или не, това ме накара да се смея силно в края на дългия работен ден. :P - person Olivier Tremblay; 21.05.2009
comment
++ за добър смях. звучи като нещо, което моят (нетехнически) съпруг би измислил. - person jess; 23.05.2009
comment
+1! Мислех, че патешкото писане включва и писане. Или патици. Или и двете. - person SqlACID; 10.06.2009

Че можете напълно да разберете даден проблем, преди да започнете да го развивате.

person Community    schedule 20.05.2009
comment
Това, приятелю, трябва да бъде: че можете напълно да разберете проблема. Но е толкова вярно. И очевидно концепция, трудна за разбиране или дори приемане. - person KarlP; 21.05.2009
comment
Не можете да разберете проблема напълно, но със сигурност ТРЯБВА да разберете проблема (до известна степен), преди да започнете да се развивате. bit.ly/kLXgL - person OscarRyz; 21.05.2009
comment
Понякога трябва да започнете да се развивате, за да разберете проблема. И/или проблемът се променя колкото повече се развивате. - person Evan Plaice; 14.06.2010

Умните хора винаги са по-умни от мен.

Наистина мога да победя себе си, когато правя грешки и често ме обвиняват, че се самоиронизирам. Преди гледах със страхопочитание на много разработчици и често предполагах, че тъй като те знаят повече от мен за X, те знаят повече от мен.

Тъй като продължавах да трупам опит и да се срещам с повече хора, започнах да осъзнавам, че често, въпреки че те знаят повече от мен по определена тема, те не са непременно по-умни от мен/вас.

Морал на историята: Никога не подценявайте това, което можете да донесете на масата.

person Community    schedule 21.05.2009
comment
добър! В момента работя с колега, който наистина знае МНОГО за разработката на .NET. Отне ми известно време, за да разбера, че разбирам по-добре от какво се нуждаят клиентите. - person Treb; 22.05.2009
comment
И от друга страна, че знам повече от другите хора. Оказва се, че те просто знаят различни неща. Другият морал: Никога не подценявайте това, което някой друг може да донесе на масата. - person thursdaysgeek; 22.05.2009
comment
Ето отново онова старо нещо „Направи на другите“... Измислям нова фраза: Техническо тормоз ~ Състоянието, когато се чувстваш превъзходен, защото знаеш някои неща, и правиш грешката да позволиш на всички останали да го знаят. @seealso: умник. - person corlettk; 23.05.2009
comment
Отлично наблюдение - моята версия е по-негативна Всеки прави глупости от време на време. Донякъде свързано с не обръщайте бита на бозо. - person peterchen; 28.05.2009
comment
Трябва да се притеснявате само когато глупавите хора са по-умни от вас. - person Brad Gilbert; 30.07.2009
comment
Доверяваме се на силата си, без да се хвалим с нея; уважаваме тази на другите, без да се страхуваме от нея - Томас Джеферсън - person krishna; 22.08.2009

Дълго време си мислех, че Лошото програмиране е нещо, което се случва на периферията.. че Правенето на нещата правилно е норма. Не съм толкова наивен тези дни.

person Community    schedule 20.05.2009
comment
Мислех, че Лошото програмиране се прави само от други програмисти, докато не бях довършен от една от моите Лоши програми. Сега правя нещата правилно! (Този път ми вярваш, нали?) - person Jared Updike; 21.05.2009
comment
OMG, бих гласувал за това отново и отново, докато щракащият ми пръст се умори като очите ми, преглеждащи кода... - person AviD; 22.05.2009
comment
Напълно. Преминах от Това никога не се случва на Това никога не се случва, освен на тази работа на Всяко място има лош код. - person Ryan Lundy; 22.05.2009
comment
Донякъде все още поддържам това убеждение. Предполагам, че не съм виждал много от това как се пише код в реалния свят (типични компании). - person hasen; 22.05.2009
comment
Хакването е норма. Инженерството е от компетенциите на истински компетентните. Ако някога срещна софтуерен инженер, ще ви уведомя. - person corlettk; 23.05.2009
comment
@corlettk: Искаш да кажеш, че маймунското кодиране е норма, нали? Хакването е изкуство, забележете, изкуство от високо ниво, което съм далеч от постигането. - person hasen; 27.05.2009
comment
@Hasen: Не, хакването е аналогия с неумело забиване на брадва в дърво, изсичане на малки парчета в луда паника без реален план и създаване на кървава голяма бъркотия, докато дървото накрая падне върху главата ви. Хак е този, който създава банална и посредствена работа с надеждата да спечели търговски успех. Никога няма да разбера защо компютърното поле промени хакване на квалифицирано. - person Lawrence Dol; 23.10.2009

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

Сега се опитвам да поддържам нещата възможно най-прости и отделени. Преработването, за да направя нещо абстрактно, е много по-лесно, отколкото да предскажа как трябва да абстрахирам нещо.

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

person Community    schedule 20.05.2009
comment
Отделен = истинска абстракция. Абстрактното само по себе си е... преждевременна оптимизация. - person Jared Updike; 21.05.2009
comment
Това върви заедно с това, което открих при настройка на производителността. Може да има прекрасна програма с множество слоеве на абстракция. Тогава работното натоварване става тежко и познайте какво струва цялото време ... всички абстракции. Компютрите изпълняват инструкции, а не абстракции. - person Mike Dunlavey; 21.05.2009
comment
Абстракцията и генерализацията са мощни инструменти, за съжаление използвани за обобщаване на абстрактен случай на употреба с едно единствено изпълнение. Смешното е, че когато има нужда от промяна на изпълнението, абстракциите и обобщенията също трябва да се променят... - person KarlP; 21.05.2009
comment
Напълно съм съгласен с Джаред ... ако сте успели да стигнете до простото и отделеното, вие сте постигнали истинска абстракция. Как могат нещата да бъдат отделени, ако не сте абстрахирали нещата в интерфейси и фабрики и т.н...? Как може да бъде просто, освен ако не премахнете всички if type = this тогава направете това, или ако типът е that тогава направете нещо друго? - person DoctorFoo; 22.05.2009
comment
И тук е така. Мисля, че научих за абстракцията преди да създам куп спагети код. Трябваше да ни научат как да вършим нещата, дори ако кодът е спагети, и след това да ни научат на OO и абстракцията. - person hasen; 22.05.2009
comment
Какво ще кажете за абстракцията, в случай че можете да я използвате в бъдеще, дори ако сега е неефективна? - person Andrew Weir; 27.05.2009
comment
Андрю, идеята, която се опитах да предам, беше, че вероятно можете да преработите кода си, когато имате нужда от него. Осъзнавам, че това е общо обобщено твърдение, но е добро правило. - person Evert; 27.05.2009
comment
Това ме хапе в момента! Мисля, че изпаднах в режим на архитектурен астронавт, когато проектирах своя софтуер, и сега, когато го внедрявам, виждам, че съм загубил много време, за да го направя много по-гъвкав от необходимото. Все още съм за абстракцията, но я плащате предварително с много усилия. Мисля, че трябваше да се съсредоточа върху създаването на нещо, което работи добре, вместо на единствената истинска система. - person A. Levy; 27.05.2009
comment
Преработването, за да направя нещо абстрактно, е много по-лесно, отколкото да предскажа как трябва да абстрахирам нещо. ‹-- - person Alex Baranosky; 17.08.2009
comment
Никога не съм разбирал значението на абстрактните класове. Разбира се, има случай 1/100, когато има смисъл да се шаблонират подкласовете, но IMHO, абстрактните базови класове се използват прекалено много. Това трябва да е обратна реакция на преподаване в университетски стил, което предполага теория == практика. - person Evan Plaice; 14.06.2010

Че жените намират компютърните програмисти за секси...

person Community    schedule 21.05.2009
comment
Чакай малко??? - person Çağdaş Tekin; 21.05.2009
comment
хе хе хе хе.. добре, търсих нещо, което да запази усмивката ми до края на деня. Мисля, че го намерих!!! :) - person OscarRyz; 21.05.2009
comment
Просто не знаех какво ни намират за несекси. Мислех, че сме като всички останали. - person hasen; 22.05.2009
comment
Средно може би не. Стигмата на маниаците изчезва, но далеч не е изчезнала напълно. Въпреки това все още има много жени, които харесват маниаци/инженери/програмисти. Просто са по-трудни за намиране и може да не направят привлекателността си очевидна. - person rashfeather; 23.05.2009
comment
Приятелката ми не е особено технически специалист и намира моето програмиране за секси :) - person Carson Myers; 02.06.2009
comment
Ох, скъпа! Да, кажи "ако" - направи ми някои изключения.. Да, знаеш как го искам :P - person cwap; 10.06.2009
comment
@rlb.usa, на моменти, да - person Randell; 28.08.2009
comment
Какво? Програмистите богати ли са? Кога се случи това? - person Filip Navara; 12.09.2009
comment
това определено е вярно. жените не те намират за секси, не останалите от нас, :P - person Dan Beam; 11.02.2010
comment
Някои жени (подходящите) са привлечени от проницателни интелигентни момчета. Което, без прототипната врат-брада и наденица-черва, са доста общи черти на програмистите. Поръсете малко загриженост за представата за себе си/хигиената и от време на време тръпката/вълнението от екстремните спортове и вече сте на път. - person Evan Plaice; 14.06.2010
comment
Жените намират мъжете със стабилни заплати за секси. Значителна част от тази група са „програмисти“ - person MickeyfAgain_BeforeExitOfSO; 12.07.2010
comment
Вярно.. :D Обичам човек, който може да програмира. - person Dian; 15.07.2010

Че качеството на софтуера ще доведе до по-големи продажби. Понякога е така, но не винаги.

person Community    schedule 20.05.2009
comment
Продавате софтуер? Така е 1999 г. - person bzlm; 20.05.2009
comment
В днешно време има много уебсайтове, базирани на абонамент... - person cgp; 20.05.2009
comment
Microsoft със сигурност прави убийство с това. - person Bill Martin; 21.05.2009
comment
трябва да го обичам, толкова е вярно. - person dr. evil; 21.05.2009
comment
Иска ми се подобряването на качеството/производителността на нашия софтуер да се счита за функция - person Tom Leys; 22.05.2009
comment
@Bill: откога Microsoft предоставя качествен софтуер? - person augustin; 30.05.2012

Че всички езици (най-вече) са създадени еднакви.

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

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

person Community    schedule 20.05.2009
comment
Смятам, че изборът на правилните библиотеки е това, което има значение. Просто така се случва, че често има съответствие 1 към 1 между езици и библиотеки... - person Kevin Montrose; 21.05.2009
comment
Но ако и двата езика за програмиране са завършени на Тюринг, тогава каква е разликата? Можете да напишете всяка програма на двата езика! ;) - person Bill the Lizard; 21.05.2009
comment
Не съм съгласен, решението какъв език да се използва е много по-малко важно от това кой всъщност ще изпълнява проекта. Като само един пример от много други по-важни решения. - person Boris Terzic; 22.05.2009
comment
Проучване, посочено в (все още) прекрасната книга за управление на проекти Peopleware, заключава, че въпреки силните мнения, породени от избора на език, няма силна разлика в производителността между езиците (с изключение на асемблирането, което е значително по-слабо от езиците от по-високо ниво). Това проучване обаче е от времето, когато Ada беше най-популярният нов език в блока, така че може би е време да повторите подобно проучване. - person Daniel Martin; 25.05.2009
comment
Въпреки че превръщането на цялостни езици прави възможно прилагането на едно и също приложение, синтаксисът и метафорите на някои езици често се поддават на определени типове проблеми - person Crippledsmurf; 27.05.2009
comment
BrainFu** е толкова завършен, колкото и python. - person hasen; 27.05.2009
comment
Помислете за извършване на COM интеграция с C# срещу VB.NET. Незадължителните параметри... Това изчезва с C# 4.0, но до този момент беше/е вярно. - person Nate; 29.05.2009
comment
Обичайната мъдрост е, че производителността в редове дебъгван код за единица време е приблизително еднаква за различните езици, докато броят редове, необходими за дадено количество функционалност, може да варира значително. - person David Thornley; 04.06.2009
comment
Това, че пълните езици на Тюринг са някак еднакво приложими, е често срещано погрешно схващане. Пълният език на Тюринг може да изчисли всичко, което машината на Тюринг може (и често се подразбира и обратното). Няма абсолютно никакви последици по отношение на производителността. Операция, която отнема линейно време на един език, може много добре да отнеме експоненциално време на друг и те пак могат да бъдат завършени по Тюринг. Има огромна разлика между това, което е теоретично изчислимо и това, което е осъществимо на практика. - person TrayMan; 10.06.2009
comment
@TrayMan, просто предположих, че коментарът на Бил Гущера е шега. - person Alex Baranosky; 17.08.2009

Че голямото съотношение коментар/код е нещо добро.

Отне ми известно време да разбера, че кодът трябва да се самодокументира. Разбира се, коментар тук и там е полезен, ако кодът не може да бъде направен по-ясен или ако има важна причина, поради която нещо се прави. Но като цяло е по-добре да отделите това време за коментар в преименуване на променливи. Той е по-чист, по-ясен и коментарите не излизат „извън синхрон“ с кода.

person Community    schedule 23.05.2009
comment
Съгласен съм с с действителния код... с изключение на коментарите на javadoc (или еквивалент). - person corlettk; 23.05.2009
comment
+1, дори не ме карай да започвам с трактатите, които писах за 10 редови функции - person wds; 27.05.2009
comment
За да добавите към това, изразът assert() е по-добър от документирането на предусловие/последусловие. Договорите за .NET 4 код могат автоматично да се превърнат и в документация! - person Robert Fraser; 31.05.2010

Това програмиране е невъзможно.

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

Тогава един ден просто седнах и прочетох някои основни уроци за начинаещи и от там си проправих път. И днес работя като програмист и обичам всяка минута от това.

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

person Community    schedule 20.05.2009
comment
благодаря за добавената основна информация. +1 - person Demi; 20.05.2009
comment
Амин! Но, хей, не прокламирайте тази гледка от покривите. Не искаме всички да знаят, че програмирането е забавно, нали? ;) ;П - person Peter Perháč; 20.05.2009
comment
MasterPeter: Ще ни даде повече храна, за да увеличим репутацията си, когато идват тук и задават въпроси. - person TheTXI; 20.05.2009
comment
Бих казал, че програмирането е трудно да се прави правилно. Въпреки това е възможно, което изглежда е вашата гледна точка. - person Steve S; 20.05.2009
comment
Добра точка, Стив, актуализирах отговора. - person Ólafur Waage; 20.05.2009
comment
@TheTXI - също добра гледна точка :)) - person Peter Perháč; 20.05.2009
comment
Аз също гласувах да го отворим отново, тъй като беше променен на CW. - person Ólafur Waage; 20.05.2009
comment
@Olafur: Благодаря ви за гласуването и за отговора. - person Demi; 20.05.2009
comment
@Olafur: Защо искаш въпросът да е wiki, но не и твоят отговор? - person gnovice; 20.05.2009
comment
Това точно отразява моя опит. Иска ми се да бях започнал по-рано сега :P - person Skilldrick; 20.05.2009
comment
Ха, и аз имах това предположение. плашещо е да гледаш код, когато си начинаещ, който не знае нищо - person Ali; 21.05.2009

„При грешка Възобновяване Следващ“ беше някакъв вид обработка на грешки

person Community    schedule 20.05.2009
comment
Чувствам ви...но във vbscript (особено asp), това беше ЕДИНСТВЕНАТА налична опция за обработка на грешки, комбинирана с разумна проверка дали действително е възникнала грешка и доста молитви. - person flatline; 20.05.2009
comment
Да... това е някакъв... просто вид, от който се радваме да се отървем - person Matthew Whited; 20.05.2009
comment
Добре?! но е. Стартирате своя блок за обработка на грешки с On Error Resume Next, опитайте нещо и след това If (err.number‹›0) след това - person jpinto3912; 21.05.2009
comment
Не е ли това единственият vbscript, еквивалентен на try catch? - person James; 22.05.2009
comment
-1: Това е вид обработка на грешки. Просто не е толкова елегантно. - person JohnFx; 23.05.2009
comment
Резюме Следващото нещо е страхотно :) Игнориране на всичко и казване Разбира се, че ще работи, аз го написах! (Направих това преди.) - person JCasso; 07.12.2009
comment
Знам, че е забавно да избирам тази конструкция, но за да бъда честен, тя е ПРЕДНАЗНАЧЕНА да се използва за вградена обработка на грешки If (Err.code=12...) - person JohnFx; 27.01.2010
comment
Още 1 причина VB да умре бърза и болезнена смърт. @jpinto3912 Добавете „‹›“ към списъка за умиране/бързо/болезнено, докато сте там. - person Evan Plaice; 14.06.2010
comment
@Evan, да, все още пиша! = през първите 30 минути стартирам vba-ing. Но да искаме VBA да умре бързо заради семантиката на try-catch и странното ‹› е малко прекалено, нали? - person jpinto3912; 15.06.2010
comment
@jpinto3912 Очевидно не съм фен на VB. Езикът има неудобна семантика и много неудобни практики, които са специални за VB. IMHO, това е макро език на MS Word, който стана много повече, отколкото някога е трябвало да бъде. Най-вече ме дразни, че е много по-трудно да се намери информация за C# в Goog, защото всичко за .NET е наводнено с наистина стари VB примери и Goog дава предимство на възрастта пред полезността в този случай. Ще си призная. Имам религиозни анти-VB възгледи. Оттук и цялата дума "смърт за неверниците" ;) - person Evan Plaice; 16.06.2010
comment
@jpinto3912 '‹›' всъщност не е толкова специфично нещо за vb. Просто ме впечатлява по грешния начин, защото "x ‹› y" буквално означава "x е по-малко от по-голямо от y". И така, x става всеобхватен, когато y е включен ;). Харесвам != защото е просто „не е равно“ - person Evan Plaice; 16.06.2010

Този софтуер за програмиране изисква силна основа във висшата математика.

Години наред, преди да започна да кодирам, винаги са ми казвали, че за да си добър програмист, трябва да си добър в алгебрата, геометрията, смятането, тригонометрията и т.н.

Десет години по-късно и само веднъж ми се наложи да направя нещо, което един осмокласник не можеше.

person Community    schedule 20.05.2009
comment
Много вярно. В повечето случаи не е нужно да сте експерт по математика. Единственият път, когато наистина имах нужда да знам математика за напреднали, беше, когато се занимавах с 3D програмиране като хоби. Всъщност това беше 3D програмирането по време на гимназията, което ме вдъхнови да обърна по-добро внимание в часовете по тригонометрия и предварителни курсове. Освен това обаче обикновено всичко, от което се нуждаете, е много елементарна математика. - person Steve Wortham; 21.05.2009
comment
Мисля, че сте били погрешно информирани. Разбира се, за да бъдете добър програмист, всъщност не е необходимо да използвате много по-високо ниво на математика, но за да разберете и приложите наистина определени концепции в компютърните науки, ще ви трябва нещо повече от осми клас математика. - person hbw; 21.05.2009
comment
Бих казал, че да се чувствате комфортно с двоичната логика (което не е толкова много математика) и как всъщност работи процесорът (разпределение на паметта, комуникация на устройството, ALU и взаимодействието с каквито и регистри да имате на вашата платформа) е много по-важно да бъдете добър програмист, отколкото задълбочено разбиране на напреднала математика. - person Martin P. Hellwig; 21.05.2009
comment
Мисля, че акцентът върху математиката е да се преподават умения за критично мислене и решаване на проблеми, а не като нещо, което бихте използвали в ежедневното компютърно програмиране. - person Zack; 21.05.2009
comment
Видът абстракция, от който се нуждаете, за да разберете напредналата математика, е много подобен на абстракцията, от която се нуждаете, за да създадете софтуер. - person OscarRyz; 21.05.2009
comment
@Zack, @Oscar - Мисля, че това е идеята зад него и това е, което академиците (включително моите професори) биха искали да вярват. Въпреки това, абстракциите за напреднала математика всъщност са МНОГО различни от абстракциите, от които се нуждаете, за да създадете действителен софтуер. Всъщност рядко се срещат хора, които се справят добре и с двете. - person AviD; 22.05.2009
comment
Мисля, че концепциите за функционално програмиране са много по-лесни за разбиране, ако имате по-здрава основа в математиката, просто защото не се плашите толкова много от синтаксиса. Изглежда познато. Направих грешката да използвам прости математически функции, за да демонстрирам концепциите за функционално програмиране, нови за C#. Някои хора веднага обявиха, че е твърде сложно. - person DoctorFoo; 22.05.2009
comment
Аз също трябва да не се съглася до известна степен. Не ИЗИСКВАМ добра основа в областта на висшата математика, но толкова много модели и концепции се основават на математически техники и за създаване на по-сложен софтуер с добро разбиране на математиката ще бъде полезно, когато пишете вашата логика и алгоритми. - person Sheff; 22.05.2009
comment
В доброто програмиране си прав. В компютърните науки е необходима здрава основа в математиката, за да се разбере наистина дълбочината на някои от темите. - person Mike Tunnicliffe; 24.05.2009
comment
Мисля, че има просто някаква корелация, а не причинно-следствена връзка. Ако ви харесва математиката, може да е по-вероятно да се насладите на някои аспекти на програмирането. - person peterchen; 28.05.2009
comment
След като започнах да работя в областта на релационната теория и управлението на данни, открих, че много от моите итеративни изчисления биха могли да бъдат обработени по-добре чрез по-добро разбиране на математическите концепции и алгоритми. Изчисление II? Може би не. Но преди смятане и тригонометрия, абсолютно. - person Chris K; 04.06.2009
comment
В моята програмна кариера единственото нещо, за което съжалявам, е, че не съм правил ПОВЕЧЕ математика. Има много усъвършенствани концепции за програмиране, които ме объркват ежедневно. (Въпреки това, това е свързано най-вече с функционално програмиране и типови системи) - person Rehno Lindeque; 04.01.2010
comment
Единствената причина, поради която ни дадоха толкова много математика в университета, беше да се уверят, че няма да изкарат всички студенти първите две години. Тестването на ученик за уменията му по математика определено е по-лесно от тестването по програмиране. - person Dimitri C.; 04.01.2010
comment
Напълно и изцяло не съм съгласен с този отговор. - person Akusete; 07.06.2010
comment
Трябваше да използвам алгоритми, базирани на mod функции през цялото време (обикновено в условни, базирани на индекси), и никога не съм научил това в осми клас. - person Lance Roberts; 12.07.2010

Това оптимизиране == пренаписване на асемблер.

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

person Community    schedule 20.05.2009
comment
Peek and Poke са вашите приятели :) - person Matthew Whited; 20.05.2009
comment
Перверзник! Кажете това на съдията! - person Shalom Craimer; 29.07.2009
comment
Тук се намесва теорията на сложността. Сглобяването обикновено е микро оптимизация. Намаляването на времевата сложност на вашите алгоритми е мястото, където се печели скорост. - person PeteT; 17.12.2009
comment
@scraimer: Хубаво ми е да те видя тук, никога не бих го очаквал ;-) - person Robert S. Barnes; 18.06.2010
comment
@ Matthew - Peek и Poke са твоите приятели :): **ИЗКЛЮЧИТЕЛНО ревнувам, че не написах това първи. - person FastAl; 08.07.2010

  • Че ръководителите на компанията се грижат за качеството на кода.
  • Че по-малко редове е по-добре.
person Community    schedule 20.05.2009
comment
на тях им пука, но трябва да комбинирате уменията на художник с уменията на работника. Всеки алгоритъм не може да бъде и произведение на изкуството. Някои от тях ще се напълнят, така че използвайте повторно по-малко използваните. Спомнете си старото правило 80/20. 80% от програмата се използва 20% от времето. Така че фокусирайте 80% върху 20% от кода и направете това ИСТИНСКО ПРОИЗВЕДЕНИЕ! :ОП - person BerggreenDK; 21.05.2009
comment
по-малко редове са по-добри! част от причината да не харесвам java като език е, че правенето на каквото и да било отнема толкова много редове код. по-малко редове код означава, че е по-лесно да промените кода си. - person Claudiu; 21.05.2009
comment
Зависи какво премахвате, за да получите по-малко редове. Ако кодът все още е четим с по-малко редове, тогава е добре. Има обаче много начини да намалите броя на редовете код, които влошават кода. - person Herms; 21.05.2009
comment
Освен когато хората вземат по-малко редове, манталитетът е далеч по-добър с верижни извиквания на метод 7 дълбоко, така че когато един от тях хвърли нулев указател, нямате представа кой е бил. Или кондензират толкова много действия в един ред, че той е дълъг 150 знака и изпълнява 4 операции. Това го прави по-трудно за четене и по-трудно за отстраняване на грешки, но не е по-бързо, нито използва по-малко памет по време на изпълнение. - person Trampas Kirk; 21.05.2009
comment
Истинският убиец на проблема с по-малкото линии е PHB. Когато мениджърът не прочете 10 000 реда от работата на вашите приятели и го сравни с вашите 1 000 реда, които той също не е прочел, той вероятно ще предположи, че работите само 1 час на ден. - person SingleNegationElimination; 22.05.2009
comment
Мисля, че трябва да правим разлика между по-малко редове и по-малко код. - person Shalom Craimer; 29.07.2009
comment
Ако вашият ред завършва на ))))) и не пишете Lisp, имате твърде малко редове. - person ; 31.07.2009
comment
НЕ ТРЯБВА (!) да е така - но как очаквате мениджърите на компания X (не се колебайте да добавите произволен тип) да разбират/хаят за качеството на кода, ако единственото нещо (поне от моя собствен опит) те разбират (за съжаление) е това: повече $$$, повече $$$ и т.н. - person sabiland; 28.08.2009

Бих казал, че съхраняването на елемента година на дата като 2 цифри беше предположение, което засегна цяло поколение разработчици. Парите, които бяха издухани през Y2K, бяха доста ужасяващи.

person Community    schedule 20.05.2009
comment
Това е единственият отговор, за който ще гласувам, въпреки че е CW, така че няма значение... - person Dan Rosenstark; 21.05.2009
comment
Добре, че съм в това само за мадамите. :-) - person MikeJ; 22.05.2009
comment
IIRC някои системи през 60-те и може би 70-те години използваха само една цифра, защото използваха по-малко памет. Дори съм виждал хартиени формуляри, където 196_ и 197_ са предварително отпечатани. - person some; 05.06.2009
comment
Все още виждам формуляри с 200_ и вероятно вече има такива с отпечатано 201_. - person Macha; 04.04.2010
comment
Тъжната част е... Unix ще има своя втори кръг през 2038 г - person Evan Plaice; 14.06.2010
comment
@Evan: Ако все още използват 32-битови машини през 2038 г. - person Billy ONeal; 12.07.2010
comment
@Billy Само защото архитектурата на машината се променя, не означава, че форматът на данните ще се промени. Съхраняването на 2 цифри на разделителната способност във формат int би направило байтов (8-битов) формат на датата и все пак това засегна тонове машини с 32-битова хардуерна архитектура в 2k. Това е само още един пример защо не позволявате на хардуерите от ниско ниво да определят формати на данни. Те щипват малко със знанието, че ще има планиран SNAFU в далечното бъдеще. - person Evan Plaice; 12.07.2010
comment
Посочването на двуцифрени години беше напълно разумно в много случаи, а двуцифрените години са напълно разумни днес в много случаи като входен или отчетен формат. Компютърните формати, които твърдят, че побират дати до година Първа, са глупави, като се има предвид, че всяка дата преди 1753 г. ще бъде безсмислена без контекст (дали 1-1-1600 означава 14 650 дни преди 1-1-2000 или нещо друго?) Времената в стил Unix ще имат известни трудности през 2038 г., но дотогава преминаването към 64 бита за живи системи с нови данни не би трябвало да е проблем; историческите данни биха били недвусмислени. - person supercat; 20.12.2010

Това, че всичко различно от вмъкване/сортиране на мехурчета е просто тъмна магия.

person Community    schedule 20.05.2009
comment
Ха-ха, харесвам този, тъй като удря близо до дома. Сортиране по-бързо от n-квадратно време?? Невъзможно! - person Ross; 20.05.2009
comment
Удивително е колко прости и очевидни изглеждат повечето алгоритми за сортиране, след като имате силно усещане за рекурсия и разделяй и владей. Дотогава повечето от тях се чувстват като черна магия. - person Brian; 20.05.2009
comment
Аз съм ИЗСЛЕДОВАТЕЛ в алгоритмите за сортиране! И все още се чувстват като черна магия. - person SPWorley; 20.05.2009
comment
Никаква рекурсия не ми помага да хвърлям мрежи за сортиране, като битонични сортове. - person SingleNegationElimination; 22.05.2009
comment
Веднъж имах ред код в моята програма, който беше дълъг и сложен и не исках да го разделям или обяснявам (това беше някаква сложна формула за осветяване), така че сложих всичко на един ред и #define' да е DARK_MAGICK и единственият коментар беше предупреждение да не се опитвате да разгадаете мистериите на тъмната магия - person Alex; 23.05.2009
comment
Арно, предполагам, че това може да се очаква. Изглежда фундаментално свойство на нашия свят е, че колкото по-отблизо погледнете нещо, толкова по-лудо става. Атоми, хора, алгоритми... каквото и да е. (Като странична бележка, току-що разбрах, че ако ме интересуват такива неща, бих го приел като основа за доказателство за съществуването на бог.) - person peterchen; 28.05.2009
comment
Bogosort е най-мистериозният от всички тях. - person Alex Beardsley; 02.06.2009

Този XML би бил наистина оперативно съвместим и четим от човека формат на данни.

person Community    schedule 20.05.2009
comment
XML не е панацея, но не бих искал да се връщам към дните, в които редовно виждах приложения, които се опитваха да свият релационни данни в единични csv файлове. - person Tony Edgecombe; 21.05.2009
comment
това е оперативно съвместим синтаксис, без съмнение. Просто синтаксисът често е най-маловажният аспект на всяко решение. - person Simon Gibbs; 21.05.2009
comment
+1, можете също да добавите малко и бързо към списъка с желания. - person MarkJ; 11.06.2009
comment
Вярно, но подобрение спрямо csv и фиксирана дължина, където без документацията сте прецакани. - person PeteT; 17.12.2009
comment
Обичам XML за стандартизацията, която донесе на форматите на данни и за правилното боравене с кодиране на знаци. Мразя обаче това, което понякога се прави използвайки XML. - person Joachim Sauer; 21.04.2010

Този C++ беше някак по същество по-добър от всички други езици.

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

Никой – и нищо – не е перфектно, винаги има място за подобрение.

person Community    schedule 20.05.2009
comment
по-добре ще ви донесе тонове не толкова омразни коментари. Но бих казал, че е един от най-бързо изпълняващите се, гъвкави, свободни от препятствия. Това също е такова, което отнема младостта ви да го научите правилно, само за да откриете, че можете да правите повече или по-малко същото приложение. (въпреки че изискват допълнителен тон или два въглища, генериращи електричество) с java или C#. - person jpinto3912; 21.05.2009
comment
@JP: Доволен съм от избора си на думи :) - person Binary Worrier; 21.05.2009
comment
Производителността е по-важна в света на бизнес приложенията. разбира се, има някои ниши, в които c++ е задължителен и единственият вариант. - person Shaw; 25.05.2009
comment
@Shaw: Наистина наскоро - за любим проект - избрах да напиша един конкретен компонент в Managed C++, чисто от съображения за производителност. Просто вече не вярвам, че е по същество превъзхождащ всички други езици. - person Binary Worrier; 25.05.2009
comment
Винаги съм приемал, че C++ е по-лош от обикновения ANSI C, просто защото проблемите, в които съм виждал C++ програмистите, са много по-сложни от неприятностите, в които съм виждал C програмистите. - person Nosredna; 28.05.2009
comment
@Nosredna: Това предположение ли е за списъка? :) - person Dale Reidy; 30.05.2009
comment
Всъщност езикът, който е по-добър от всички останали, е Common Lisp. C++ обаче не е лош. - person David Thornley; 04.06.2009

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

person Community    schedule 20.05.2009
comment
Мисля, че това се нарича живот. - person Robin Day; 20.05.2009
comment
хммм.. време е да спасите тази компания. .. - person jpinto3912; 21.05.2009
comment
@jpinto3912: Не. Защото следващата компания също ще бъде част от живота (вижте предишния коментар). - person Treb; 22.05.2009

Мислех, че основните модели за проектиране са страхотни, когато бяха въведени в клас по CS. Бях програмирал около 8 години като хоби преди това и наистина нямах солидно разбиране как да създавам добри абстракции.

Дизайнерските модели се чувстваха като магия; бихте могли да правите наистина чисти неща. По-късно открих функционалното програмиране (чрез Mozart/Oz, OCaml, по-късно Scala, Haskell и Clojure) и тогава разбрах, че много от моделите са просто шаблони или допълнителна сложност, защото езикът не беше достатъчно изразителен.

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

person Community    schedule 20.05.2009
comment
много от моделите бяха просто шаблонни или допълнителна сложност, защото езикът не беше достатъчно изразителен. Експресивността е просто шаблонен код, вграден в езика. - person Unknown; 21.05.2009
comment
Не е вярно, как е шаблонно да имаш първокласни неща, вместо да ограничаваш възможностите на програмиста, както в случая с функции от по-висок ред. Липсите са красив пример за това. - person egaga; 21.05.2009

През първите няколко години, когато програмирах, не разбрах, че технически 1 Kbyte е 1024 байта, а не 1000. Винаги съм бил малко объркан от факта, че размерите на файловете ми с данни изглеждаха малко по-различни от това, което очаквах. бъда.

person Community    schedule 20.05.2009
comment
Производителите на твърди дискове все още не са разбрали... - person Michael Myers; 20.05.2009
comment
@mmyers Мисля, че имате предвид търговците на твърди дискове, нали? Или дисковете всъщност са изградени така? - person Instantsoup; 20.05.2009
comment
добре, те ще произведат устройство с 300 милиарда байта и ще го нарекат 300GB, когато 300GB (е за повечето намерения) 300 x 2^30. (7,3% разлика там!) - person nickf; 20.05.2009
comment
Има една глупава (и рядко използвана) формална дефиниция на 1024: kibi-. Както в A Commodore 64 има 64 Kibibytes памет. уф В някои случаи е объркващо. Някои специфични области на компютрите използват K=1000 като мрежови битрейт (Kbit/s), а други го използват за маркетингови причини (предимно HD). Размерите на паметта и файловете обикновено се цитират в K=1024/и т.н. - person jesup; 20.05.2009
comment
Може да се датирам с това твърдение, но всеки път, когато видя/чуя думата Kibibytes, се сещам за онзи герой от Fat Albert (Mushmouth, мисля), който добавяше Б към всичко, което каза. Пробаграмирането е ужасно жестоко. - person gnovice; 20.05.2009
comment
Хей, спри да мразиш kibi. MeBi и KiBi са поне еднозначни. - person bzlm; 20.05.2009
comment
Kilo означава 1000, Mega означава 1000000, Giga означава 1000000000. Производителите на RAM и OS са сбъркали, а не производителите на устройства. - person Mark Ransom; 20.05.2009
comment
@Mark Ransom: Всъщност не производителите на RAM/OS са сгрешили. В двоичен код 1024 е 10 бита, всички зададени на 1, това е хубава кръгла цифра [10000000000], тъй като всички данни се съхраняват в двоичен код, има смисъл да се използва KB като 1024. Това, което е изостанало е, че всеки използва различни стандарти. Всички трябва да използват едното или другото, независимо кое избират и да спрат да объркват всички... - person BenAlabaster; 20.05.2009
comment
Тези префикси имаха определено значение много преди някой да се опита да ги адаптира към двоични числа. Не трябва да знаете контекста, за да дешифрирате значението на префикса. Разбирам как се получи това, но мисля, че беше грешка, която причиняваше объркване твърде дълго. - person Mark Ransom; 20.05.2009
comment
Уау, изглежда, че неволно предизвиках доста вражда. =) - person gnovice; 20.05.2009
comment
Никой ли няма да го направи? Сериозно? Добре, ще го направя... xkcd.com/394 - person Erik Forbes; 20.05.2009
comment
Може би трябва да се върнем към двоично кодиран десетичен... математическите функции биха направили по-малко грешки... разбира се, те ще бъдат по-бавни и ще използват повече RAM, но на кого му пука :) (4-ти пъти чар) - person Matthew Whited; 20.05.2009
comment
IIRC IBM използва 2k48 и 4k96 (приблизително размера на паметта на техните мейнфрейми) през шейсетте години, а в неофициалните разговори беше само 4k. В началото се използваха само малки числа и разликата беше толкова малка, че никой не се интересуваше или всеки знаеше от контекста дали 1k означава 1000 или 1024. - person some; 05.06.2009
comment
@BenAlabaster: Всъщност 1024 (1 KiB) е 2^10 или двоично 10000000000, което със сигурност не 10 бита, всички зададени на 1. И Марк е съвсем прав, дефинициите на Kilo и Mega бяха около и дефинирани в инженерните кръгове много преди компютърните момчета да ги заемат за свои собствени (неточни) цели. Време е компютърните маниаци като нас да го оставят, да признаят, че са грешали, и да започнат да използват правилната нотация, за да означават правилното нещо. - person Lawrence Dol; 23.10.2009

Това условие се проверява като:

if (condition1 && condition2 && condition3)

се изпълняват в неопределен ред...

person Community    schedule 20.05.2009
comment
На какъв език? Езици като C/C++, Java и Python гарантират, че условията се оценяват отляво надясно и тази оценка спира при първото условие, което връща false. Това е част от спецификацията на езика. Предполагам, че повечето други езици дават същата гаранция. - person Clint Miller; 20.05.2009
comment
@Clint: Да, следователно това се оказа неправилно. - person bzlm; 20.05.2009
comment
да, този е готин. това прави писаните неща като if(myList!=null && myList.Count ›= 0) {do stuff();} много по-лесни - person Zack; 20.05.2009
comment
всъщност това зависи от езика и & ще оцени всички условия (не пряк път). Виждал съм много хора да използват And (&) във VB вместо AndAlso (&&) - person Lucas; 21.05.2009
comment
Чакай, как работи това в C#? Ако направя if (object != null && object.property == true), съм почти сигурен, че всъщност ще се срине при null.... - person Damien; 21.05.2009
comment
@Damien: В C# няма да го изпробвате сами. В pre .net VB това ще се срине. - person Binary Worrier; 21.05.2009
comment
Научих ново нещо, прав си, в реда на нещата. - person Damien; 21.05.2009
comment
. . . Всъщност ще се срине и във VB.net, освен ако не използвате AndAlso за коментара на Лукас - person Binary Worrier; 21.05.2009
comment
Някои езици нямат посочен ред. За езиците, които го правят, обикновено се хвалят как имат логика на късо съединение. - person Unknown; 21.05.2009
comment
В преди .NET VB нямаше оператори за късо съединение, така че && нямаше да се компилира. - person DoctorFoo; 22.05.2009
comment
LOL, и за да бъдем точни, както каза Binary, няма && или &. - person DoctorFoo; 22.05.2009
comment
в C++ те могат да се изпълняват в неопределен ред AFAIR. - person Krzysztof Kozmic; 27.05.2009
comment
в C++ е отляво надясно. Това ви позволява да проверите дали обектът е нулев първо в най-лявото място. if (!object==null && object.getItem()==5) - person Alex; 29.05.2009
comment
Докато четох това си спомних, че всъщност ми казаха в моя CS клас, че не мога да се доверя на реда за изпълнение и ни казаха да напишем =› if(x!=null) if(x.getX()==5) ‹= така че винаги ще работи. Съвсем забравих за това досега :) - person edorian; 11.08.2010
comment
Имайте предвид, че в C/C++ аргументите на функцията се изпълняват в неопределен ред. Например:printf("%d, %d\n", i++, i); - person Joey Adams; 19.09.2010

Че моето програмиране ще бъде по-бързо и по-добро, ако го изпълнявам сам.

person Community    schedule 20.05.2009
comment
Но не може да стане толкова грозно, колкото програмирането по двойки :-) с изключение може би на вашия код - person Egg; 22.05.2009
comment
Всичко зависи от другия човек. =) - person JohnFx; 23.05.2009

"Проектът ще бъде готов за 2 седмици"

и

„Изпълнението ще отнеме 2 часа“

person Community    schedule 21.05.2009
comment
Сега винаги вземам това време x2 или x3. Ако доставих навреме, тогава ще бъда похвален колко бързо е било това - person Eric; 21.05.2009
comment
Да, и след това прекарваш 3 часа само в борба с глупав бъг, а те си мислят, че не правиш нищо. Разкажи ми. - person hasen; 22.05.2009
comment
@Eric: Да, правя това от известно време и се получава страхотно. Дори мога да си взема отпуск (аз съм самостоятелно заето лице, а не отсъствам!). - person DisgruntledGoat; 05.07.2009
comment
+1, защото ще стане след две седмици! се превърна в такава шега с мен, че трябва психически да се удрям всеки път, когато сериозно давам оценка, която отново е две седмици. - person BlairHippo; 06.11.2009

Че мога да разбера собствения си код без коментари!!!

person Community    schedule 21.06.2009
comment
Боли, когато осъзнаеш, че не можеш да го разбереш! - person Luc M; 04.04.2010
comment
Това е, когато знаеш, че си свършил лоша работа, като си го написал ;) Но да, боли :( - person Michal Ciechan; 18.04.2010
comment
На подобна бележка: че мога да разбера коментарите си - person edorian; 11.08.2010

Мислех, че ще ми трябва.

person Community    schedule 21.05.2009
comment
Обяснение на шегата: Репликата е обратното на YAGNI (няма да ви трябва). По същество мислех, че ще имам нужда от клас/модул/функционалност/и т.н., преди да мога да завърша програмата си. - person MrValdez; 21.05.2009
comment
Отдавна си мислех, че трябва да има противоположен принцип: BWIIDNI? - person Daniel Earwicker; 27.05.2009

Че динамично въведените езици като Python или Ruby са по някакъв начин по-малко квалифицирани за използване в големи проекти.

person Community    schedule 21.05.2009
comment
Имах същото събуждане около 2000 г. Прочетох някои неща в оригиналното уики на www.c2.com и в крайна сметка започнах тази страница: c2.com/cgi/wiki?UnificationOfStaticTypesAndUnitTests и бях на ръба да заключя, че съм ирационално привързан към статичното писане. Но оттогава започнах да използвам среда (C#), в която статичното въвеждане наистина вдъхва живот на IDE по време на редактиране, и сега съм почти убеден, че статично въведените езици са по-добри, защото с тях се работи по-лесно. Няма динамично въведен език, който да не бъде подобрен с информация за статичен тип! :) - person Daniel Earwicker; 27.05.2009
comment
Статично въведеното може да направи IDE безкрайно по-добро, докато динамичното въведено може да направи кода безкрайно по-кратък. Необходима е черна магия, за да се огъне статично въведен език, за да се разрушат границите, докато динамично въведените езици често нямат достатъчно или ясно дефинирани граници. Изберете вашата отрова. - person Evan Plaice; 14.06.2010
comment
Възможно е да имате хубав кратък код на статично въведен език; вижте Haskell и boo. - person Qwertie; 09.07.2010

Едно предположение, което имах като новобранец в онези дни, беше, че хората с повече години в областта автоматично са по-добри разработчици.

person Community    schedule 27.05.2009
comment
Защо не мога да гласувам за вас два пъти? - person Luc M; 08.06.2009
comment
+1, но и обратното, че разбирах проблема по-добре и можех да измисля по-добро решение от старшия разработчик. - person Nathan Koop; 03.07.2009

Това е неудобно, но дълго време не разбирах разликата между референтните типове и стойностните типове. Мислех, че трябва да използвате ключовата дума ref, за да промените обект в различен метод.

Това е една от най-фундаменталните концепции за C#, които трябваше да знам.

person Community    schedule 20.05.2009
comment
Ще се изненадате колко разработчици не знаят разликата. - person DoctorFoo; 22.05.2009
comment
Когато провеждах телефонни интервюта, винаги имах въпрос към кандидата за това, защото често се разбира погрешно. - person Ryan Lundy; 22.05.2009
comment
...и повечето от тях го пропуснаха. Те биха могли да обяснят разликата между предаване по стойност и предаване по референция за типове стойности, но малко от тях са я измъчвали за референтни типове. - person Ryan Lundy; 22.05.2009
comment
поправете ме, ако греша (не съм 100% сигурен) типове стойност = int/bool/decimal и т.н. и референтни типове = класове? - person Michal Ciechan; 18.04.2010
comment
@LnDCobra ти си прав и грешен. Класовете са фундаментално референтни типове, но типовете стойности (int, bool, decimal) също могат да бъдат предавани чрез референция с помощта на ключовата дума ref. - person Evan Plaice; 14.06.2010

Това е наистина неудобно, но когато започвах да се уча как да програмирам, нищо не можеше да ме задоволи. Исках да пиша видео игри. Не тривиалните малки програми, които всички тези книги искаха да напиша. Затова реших, че лесно мога да пропусна 10 глави и да пренебрегна основите.

Така че основно пренебрегнах променливите!

Проблемът беше, че не разпознах ключови думи от конвенциите:

Car car = new Car(); //good
Car test = new Car(); //wrong must be lowercase car!

for (int i = 0; i < 10; i++) //good
for (int test = 0; test < 10; test++)//wrong must be i

Правих това повече от година и дори направих тик-так игра с 3000 реда! В този момент бях развълнуван от страхотността си, докато не намерих тик-так в 150 реда в Интернет. Тогава осъзнах, че съм идиот и започнах отначало.

person Community    schedule 25.05.2009
comment
tica tac toe в 3000 реда, закон - person Petey B; 05.06.2009
comment
Напомня ми, когато направих първия си базов и не осъзнах, че $str във входа $str може да се наименува почти всичко. - person Viktor Sehr; 16.05.2010
comment
Невежеството не е почти същото нещо като идиотизма. Изглежда, че си се поучил от него. Всички сме започнали от някъде! - person Stephen Waits; 23.03.2011

Това програмиране е лесно.

person Community    schedule 20.05.2009
comment
Какво ще кажете за програмирането по-конкретно? - person Demi; 20.05.2009
comment
Програмирането е лесно. Програмирането добре или правилното програмиране не е толкова лесно. - person jmucchiello; 21.05.2009
comment
Наистина ли? Никога не съм забелязвал... Просто реших, че умовете, които са настроени към добро програмиране, са рядкост... - person AviD; 22.05.2009

Че операционните системи Unix и Linux са добре проектирани ... Вероятно трябва да квалифицирам това (!)

Първо, гледната точка е подсилена от такива анти-труизми като:

  • всяка следваща разработена ОС завършва с лошо преработване на Unix (казва се и за Lisp, където е по-вярно).
  • списъкът с правила, които правят „философията на Unix“. Не че грешат, това е внушението, че самият Unix ги следва отблизо.

Може да е по-вярно да се каже, че те са добре проектирани/добре направени и със сигурност части от тях са, но дори това е само относителна преценка, спрямо някои ужасни версии на Windows. Ето няколко примера за неща, които са направени зле:

  • конфигурацията е бъркотия, ad-hoc конфигурациите на плоски файлове не са добри
  • езикът за програмиране C трябваше да бъде заменен (с нещо като D) дълъг преди време
  • shell скриптовете са шизофренични. Не е добър за разработка, тъй като е стенограма, предназначена за бързо писане.
  • структурите на директории са неправилно именувани
  • веригата от инструменти на GNU е ненужно тайнствена
  • вярата, че общата цел винаги има предимство пред специалната цел

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

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

person Community    schedule 20.05.2009
comment
По-добре е проектиран от Windows... - person Zifre; 22.05.2009
comment
Все още мисля, че конфигурацията с плоски файлове е по-добра, но ad-hoc е катастрофа. Струва ми се, че механизмът plist на MacOS X прави много добър компромис - person SingleNegationElimination; 22.05.2009
comment
Мисля, че общата гледна точка остава: Linux носи много глупости, малко като Windows. но вашите конкретни точки не ме убеждават наистина, конфигурацията работи добре за повечето неща (зависи от това как са внедрени конфигурационните файлове), скриптовете на обвивката вече се правят често с python, структурата на директориите е според вкуса, ... Малко слаба наистина ли - person wds; 27.05.2009
comment
Вероятно има „по-добри“ отрицателни точки - не го използвам редовно от известно време, но смятате ли, че може би имате ниски стандарти по отношение на това. Conf работи, но не добре - но наистина трябва да има стандарт (с информация за типа), който би направил възможни неща като чувствителна към контекста помощ и прилични инструменти за графичен интерфейс (които могат да обработват всички версии на conf файлове например). IMHO на вашето POV липсва визия за това. - person mike g; 27.05.2009
comment
Това не е просто шел скрипт. Съществува пълна липса на разделение между човешкия интерфейс (интерактивната обвивка) и инженерния интерфейс (програмите). Shell е изкривил API за програмите и е торпилирал една от целите на unix (всичко като малки програми). Изход като текст, който може да се чете от човек, и въвеждане като превключватели за запазване при въвеждане на един символ. Вземете rm (пример за играчка) #това е добре за експертен команден ред rm -f #трябва да бъде нещо подобно в скриптовете remove force=true Човешкият слой трябва да е отделен слой. - person mike g; 27.05.2009
comment
Няма да говоря много за именуването на dir, но идеята, че е напълно субективно, е погрешна според мен. - person mike g; 27.05.2009
comment
Някои от нас смятаха, че Unix е преработил Multics лошо. Unix беше умишлено проектиран, за да избегне да бъде всичко, което беше Multics, а след това останалото беше хакнато, вместо да бъде проектирано. - person Windows programmer; 08.06.2009
comment
Бих казал, че *nix като цяло са по-сигурни и някои марки (в моя случай Linux Mint) са по-стабилни. Пуснете Norton на Windows и моят *nix ще изгори windows всеки ден в изпълнение. По-добре проектиран? не е задължително. По-добре като цяло? да Странична бележка: Рядко съм докосвал конфигурационен файл в Mint. Почти всичко може да се направи с GUI. - person Evan Plaice; 15.06.2010
comment
Linux не е повреден от нуждите на бизнеса?! Толкова много висши идеи са били отхвърлени заради по-низши. Linux днес е предимно политика: бившият ми колега се потруди, за да приеме корекцията си в ядрото на linux (леко подобрение на TCP протокола). Той би могъл да разкаже много интересни истории за хора, които се опитват да блокират/саботират приемането на корекция по много съмнителни и понякога неправилни технически причини и предположения. - person zvrba; 12.07.2010

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

person Community    schedule 19.06.2009
comment
@Mark, и че хората, които са ти казали какво е правилно, няма да кажат нещо просто, защото всъщност не са знаели отговора. (-: - person Rob Wells; 19.06.2009
comment
Това е смешно, най-голямата ми погрешна представа, когато станах старши разработчик, беше, че очаквах завършилите университет да знаят какво правят. :-) - person tnyfst; 19.06.2009
comment
@Mark: LOL @tnyfst: LOL отново ;-) - person Treb; 20.06.2009

Добре, научих програмиране доста рано. Бях на около 14 години. И имах всякакви луди вярвания, но не ме питайте за точния момент, защото това беше преди… много време.

  • Добре, така, за известно време вярвах, че ако използвате термина синхронизиране в Java, тогава Java решава това неприятно нещо със синхронизиране вместо вас

  • Вярвах поне половин година, вероятно повече, че статичното писане ще подобри производителността.

  • Вярвах, че освобождаването на нещо ще върне паметта обратно на операционната система.

  • Вярвах, че извикванията на malloc се свеждат до проверка дали има достатъчно свободно място в операционната система, така че malloc не би бил скъп.

  • Дълго време си мислех, че Java е създадена с мисъл за всички предимства и недостатъци на другите езици, в „перфектна комбинация“, която ще вземе най-добрите свойства на другите езици и ще отхвърли грешките.

  • Силно надцених броя на случаите, в които LinkedLists превъзхождат ArrayLists.

  • Мислех, че NP-твърдостта е доказателство, че нито един СЛУЧАЙ не може да бъде разрешен ефективно, което е тривиално невярно за известно време.

  • Мислех, че намирането на най-добрия полетен план в уеб сайтовете на туристическите агенции ще отнеме толкова много време поради „проблема с пътуващия търговец“, тъй като гордо се засмях на роднините си (когато бях малък, нали?!)

Може да измисли повече. Нямам представа колко време се придържах към всеки от тях. съжалявам

PS:
Ааа, добре, този се изчисти не толкова бавно, но виждам, че начинаещите го правят от време на време, така че си помислих, че може да се интересувате: Мислех също, че за да съхранявате несигурен брой неща, ще трябва да декларирам нова променлива за всяка. Така че бих създал променливи a1, a2, a3, ..., вместо да използвам една променлива a, която бих декларирал като вектор.

person Community    schedule 20.05.2009
comment
Не, не - трябва да създадете a1, a2, a3 и т.н., но ВСИЧКИ те трябва да са вектори. - person AviD; 24.05.2009
comment
Този пътуващ търговец просто ми направи деня. :Д - person Andrew Szeto; 15.07.2009
comment
Чакай, значи след половин година твоята статично типизирана програма работи по-бавно? Паметта става дълга, когато я освободите? свободно място в ОС? ...?! - person Qwertie; 09.07.2010

Това е работа 9-5

person Community    schedule 22.05.2009

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

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

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

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

person Community    schedule 20.05.2009
comment
Някой друг е загубил глас само за да мога да гласувам за това. - person UnkwnTech; 21.05.2009
comment
Моят личен фаворит е този вид разговор: BA: Системата изисква тези резултати. || Аз: Добре, ще ни трябват тези данни. || БА: Но въвеждането на данни ще струва милиони! || Аз: Да, и откъде очаквахте системата да вземе тези данни? || БА: Не можеш ли да го измислиш? - person corlettk; 23.05.2009
comment
Последната ви точка е, че липсват адвокати и броячи на боб, за да отидете с цялата част за бича на човешката раса - person Evan Plaice; 14.06.2010

Възможно е да нямате без дефекти преди пускане на живо.

Определено не е вярно, дори дефектите на P2 остават отворени понякога.

person Community    schedule 20.05.2009
comment
Какво ще кажете за предположението, че вашите вътрешни имена за нивата на приоритет са моите вътрешни имена за нивата на приоритет? Тук това, което наричате TPS отчети, се нарича SRP отчети! ;) - person Doug McClean; 19.06.2009

Тези прегледи на кодове са загуба на време.

След като преминах от компания, в която те бяха изцяло незадължителни, към такава, в която са задължителни (дори одитирани), разбрах тяхната полезност. Наличието на втори поглед върху кода, дори и върху най-тривиалните части, може:

A) ви спестява неудобството, когато прецакате нещо тривиално (тривиален преглед на кода, например, би ни попречил да изпратим спам на стотици имейли до нашите клиенти, на предишната ми работа)

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

C) най-малкото се уверете, че някой друг освен вас знае как работят нещата.

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

person Community    schedule 21.05.2009
comment
Първото ми запознаване с прегледите на кодове беше в организация, която всъщност не вярваше в тях, но искаше да каже, че са ги направили. Когато имах първия си опит с raal честен преглед на кода, беше малко шок. - person Mark Bessey; 13.08.2009

Че ако условията бяха оценени на всеки ред и ако напишете код като този:

Dim a as Boolean = True
If a Then
    Console.WriteLine("1")
    a = False
    Console.WriteLine("2")
Else
    Console.WriteLine("3")
End If

Тогава изходът ще бъде:

1
3
person Community    schedule 20.05.2009
comment
Това е едно погрешно схващане, за което никога не съм имал/чувал. - person Brad Gilbert; 21.05.2009
comment
Някои от моите приятели играеха на тази игра за програмиране на роботи, където това всъщност беше случаят на полу-измисления език, на който програмирахте своя „бот“. - person Zarkonnen; 21.05.2009
comment
Това е страхотно. Това е единственият отговор, за който гласувам, с изключение на този друг отговор, за който гласувах. Нещо подобно се случва, когато итерирате през масив и се опитвате да премахнете елементи от масива... - person Dan Rosenstark; 21.05.2009
comment
По дяволите, това няма ли да е спирачка за шоуто? - person NTDLS; 29.05.2009
comment
Нямаше ли да разберете, че това не е вярно първия път, когато го прегледахте с дебъгера? - person John MacIntyre; 04.06.2009
comment
Приблизително така работят условните инструкции на ARM. Всички те имат шаблон "if (a) then ..." (или NOT a), където a е един от флаговете на процесора. Тъй като условните скокове не са много бързи, има смисъл да имате няколко условни инструкции с едно и също условие подред. Но ако сте променили този флаг на условието наполовина, следващите инструкции ще използват новата стойност на флага. - person MSalters; 31.08.2009
comment
Чудя се има ли ситуации, в които тази логика действително може да бъде полезна? - person Max Yankov; 06.07.2011

Че дизайнът на операционната система NT е недостатъчен в сравнение с UNIX. Оказа се, че ядрото на NT и дизайнерските решения са много подобни на всяка съвременна UNIX-подобна система и че повечето от проблемите, които получавате в ядрото, са резултат от бъгови драйвери на трети страни, написани от бъгови компании.

person Community    schedule 21.05.2009
comment
Аз протестирам. Едно фундаментално нещо разграничава windows от unix. Управление на паметта. Windows открива опит за проникване. Unix открива опит за проникване... така че програмите на Windows могат и използват неразпределена памет. Да! - person corlettk; 23.05.2009
comment
@corlettk - имаш ли някакви препратки за това какво имаш предвид с това? - person Daniel Earwicker; 27.05.2009
comment
Така или иначе е грешно. Съответният механизъм на Windows са таблици на страници. Той предполага, че Windows VirtualAlloc() е всичко и ви трябва само VirtualProtect, за да поискате разрешение. Цялата нужда от VirtualAlloc() до голяма степен го доказва, че греши. - person MSalters; 31.08.2009
comment
Windows блокира RAW пакети от „съображения за сигурност“. Ако сигурността е извинение да се блокира нещо, не трябва ли да блокират целия интернет? Наф каза... - person Evan Plaice; 14.06.2010

Че бях добър програмист!

person Community    schedule 27.05.2009
comment
За първите ми няколко работни места бях единственият програмист в отдела и мислех, че съм доста готин човек. След това си намерих работа в екип с други програмисти. Това ми отвори очите. - person Joe White; 03.02.2011

Че .NET структурите (C# и VB.NET) са референтни типове, точно като класове.

„Получих“ тази мъдрост в някакъв момент малко преди или след като .NET 1.0 пристигна на сцената (нямам представа откъде, може да е изскочила изцяло от ума ми, като Атина от челото на Зевс) и го запази, докато Джон Скийт не разубеди идеята преди около 4 месеца.

Благодаря Джон.

P.S. Не е свързано с програмиране, но аз също вярвах (до преди около 5 минути), че "Аполон изскочи цял от челото на Зевс".

person Community    schedule 20.05.2009
comment
Атина произлиза от челото на Зевс. Аполон е роден по старомодния начин - person Brian Postow; 20.05.2009
comment
Това показва, че не съм посещавал университет, никога не съм учил класиката правилно. . . О, срамота. . . - person Binary Worrier; 20.05.2009
comment
Ако използвате Vb.Net, вие изучавате класиката всеки ден. - person bzlm; 20.05.2009
comment
Гласува само за първия коментар и последното изречение. - person Michael Myers; 20.05.2009
comment
В C++ struct е същото като class, така че повечето хора, които идват на C#, приемат, че тук е същото. - person kubal5003; 24.06.2010

Че байтовете и знаците са практически едно и също нещо - "ASCII" е просто начин за картографиране на стойност на байт към глиф на екрана.

Четенето за Unicode наистина ми отвори очите (въпреки че все още не го разбирам напълно).

person Community    schedule 22.05.2009
comment
Страхотна статия: joelonsoftware.com/articles/Unicode.html - person corlettk; 23.05.2009
comment
Наистина, нещата изобщо не стават сложни, докато не откриете за транскодиращите таблици, които са в отделните файлове с шрифтове. - person SingleNegationElimination; 05.07.2009
comment
Това много често срещано погрешно схващане бавно се заменя с погрешното схващане, че Unicode символът е 2 байта. Целият стандарт е дефиниран за разширение и символите винаги ще бъдат с променлива дължина -- особено когато нормализирането на Unicode влезе в картината. - person André Caron; 01.06.2011

Че един ден ще имам реалистична представа колко време ще отнеме изграждането на някакъв нетривиален код/система/каквото и да е.

person Community    schedule 27.05.2009
comment
И ако имате добра оценка, това е защото сте напреднали дотам, че подобни проекти са тривиални за вас :-) - person Shalom Craimer; 29.07.2009

Предполагах, че е достатъчно да програмирам Win32 приложения.

Също така, че всяка програма трябва да идва с GUI, тъй като командният ред е "остарял".

person Community    schedule 20.05.2009
comment
+1 Тези определено са успешни. - person Evan Plaice; 14.06.2010

Мога да чета SO и да свърша всяка работа.

person Community    schedule 08.07.2010
comment
Точно това се опитвам да направя в момента. - person ollb; 19.12.2010

Мислех, че всичко, което трябва да направя, за да подобря производителността на базата данни, е да я поставя в 3-та нормална форма.

person Community    schedule 20.05.2009

Тази обектна ориентация винаги е най-добрият начин за проектиране на изходния код и винаги ще бъде.

person Community    schedule 08.06.2009
comment
хехе, разкажи ми за това. Тези дни мразя ООП - person hasen; 01.09.2009
comment
Ruby щеше да е ад без ООП. - person ; 14.02.2011

Че този:

SomeClass object(initialValue);

и този:

SomeClass object = initialValue;

бяха гарантирано еквивалентни в C++. Мислех, че втората форма гарантирано ще бъде интерпретирана така, сякаш е написана като първа форма. Не е така: вижте Синтаксис за инициализация на C++.

person Community    schedule 20.05.2009
comment
Само преди няколко дни направих тази грешка в отговор, който дадох на SO. - person Mark Ransom; 20.05.2009

Назад, когато програмирах на TI-83, мислех, че не можеш да присвоиш променлива сама на себе си. Така че (пренебрегвайки, че това е C код, а не TI-BASIC), вместо да пишете

c = c + 1;

щях да пиша

d = c + 1;
c = d;

Когато научих за += и ++, това ме порази.

person Community    schedule 20.05.2009
comment
и след това научихте, че някои езици нямат такива и часовникът се връща назад. - person Dan Rosenstark; 21.05.2009
comment
Поне разбрах, че ако написах c++, това е еквивалентно на c = c + 1, така че не беше върнато много назад. - person Chris Lutz; 21.05.2009
comment
Първо израснах на Visual Basic (първа програма на 6-7), така че бях отгледан с итератори. - person Dmitri Farkov; 22.05.2009
comment
Мечтаех да създам BASIC интерпретатор с точно този вид мозъчно увреждане. - person SingleNegationElimination; 22.05.2009

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

  • Всички заинтересовани страни ще вземат обективни решения относно софтуерния дизайн. Тези, които не са въвлечени в писането на кода, вземат всякакви решения, базирани изцяло на емоции, които не винаги имат смисъл за нас, разработчиците.
  • Бюджетите на проекти винаги имат смисъл – Виждал съм компании, които са доста щастливи да отделят [само например] $50 000 на месец в продължение на години, вместо да плащат $250 000, за да завършат проект за 6 месеца. Правителството например губи годишния си бюджет, ако не го похарчи - така че ще го похарчи, по дяволите или при висока вода. Изумява ме колко долари за проекти се губят за неща като това.
  • Винаги трябва да използвате правилните инструменти за правилната работа - понякога това решение не е във вашите ръце. Понякога от високо се спуска, че "трябва да използваш технологията X" за този проект, оставяйки те да си мислиш "WTF! На кого му хрумна тази нелепа идея?".. .човекът, който плаща заплатата ви, ето кой, сега го свършете.
  • Идеологията на програмирането е на първо място, всичко останало е на втори план. В действителност крайните срокове и бизнес целите трябва да бъдат спазени, за да получите заплатата си. Понякога вземате най-лошите решения, защото просто нямате време да го направите по правилния начин... точно както понякога тази дума е на върха на езика ви, но минутата, която е необходима, за да си я припомните ви кара да изберете различна и по-малко идеална дума. Не винаги има време да го направиш както трябва, понякога има само време да го направиш - каквото и да е това. Оттук често срещани анти-шаблони, използвани от така наречените опитни разработчици, които трябва да измислят решение на проблем 10 минути преди крайния срок за представяне на софтуера, доставен на най-добрия ви клиент утре.
person Community    schedule 20.05.2009

Че IDE ще станат по-бързи.

person Community    schedule 23.05.2009
comment
Тенденцията продължава с VS 2010 :( - person Ben Aston; 09.05.2010
comment
Поне получавате нещо за това. По-новите IDE вършат работата си по-добре от тези от преди известно време. - person Billy ONeal; 12.07.2010

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

person Community    schedule 20.05.2009

Че XML пространствата от имена (или по-лошо, добре оформените) са по някакъв начин по-трудни, отколкото да се опитвате да правите без тях.

Много често срещана грешка, дори в W3C!

person Community    schedule 20.05.2009
comment
Не че са по-лоши. Това е, че те вземат език, който вече е доста грозен/многословен, и го правят много по-грозен/многословен. - person Evan Plaice; 15.06.2010

Моето неправилно предположение: Въпреки че винаги има място за подобрение, в моя случай аз съм толкова добър програмист, колкото мога да бъда.

Когато за първи път излязох от колежа, вече програмирах C от 6 години, знаех всичко за "структурираното програмиране", мислех, че "OO" е просто прищявка и си помислих "човече, добър съм!!"

10 години по-късно си мислех „Добре, тогава не бях толкова добър, колкото си мислех... сега схванах идеите за полиморфизъм и как да пиша чисти OO програми... сега съм наистина добре".

Така че по някакъв начин винаги бях наистина добър, но също така винаги ставах много по-добър от преди.

Стотинката падна не след дълго и най-накрая имам "малко" смирение. Винаги има още какво да научите (тепърва трябва да напишете подходяща програма на чисто функционален език като Haskell).

person Community    schedule 21.05.2009
comment
Подкрепям предложението. Никой не е и наполовина толкова добър, колкото си мисли, но това изглежда не пречи на умните да учат. Тъпите упорстват с илюзии за адекватност въпреки всички доказателства за противното; и отказват да учат или да бъдат научени. - person corlettk; 23.05.2009

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

person Community    schedule 29.07.2009
comment
Торвалдс има подобен цитат за Linux - само че неговата цифра е под пет секунди - person new123456; 23.02.2011

В C++ дълго време си мислех, че компилаторът отхвърля вашия, когато дава дефиниция за чист виртуален метод.

Бях учуден, когато разбрах, че съм сбъркал.

Много пъти, когато кажа на някой друг да даде имплементация по подразбиране на своя чист виртуален деструктор за неговия абстрактен клас, той/тя ме поглежда с ГОЛЕМИ очи. И знам оттук, че ще последва дълга дискусия ... Изглежда, че е общоприето вярване, донякъде разпространено сред начинаещите в C++ (както и аз се смятам за .. Все още уча в момента!)

wikipedia връзка към чистите виртуални методи на c++

person Community    schedule 20.05.2009
comment
Мамка му! Ще разпитам всички мои приятели с опит в C++, за да видя дали някой от тях знае това, защото аз със сигурност не знаех. - person KeyserSoze; 20.05.2009
comment
През повечето време няма смисъл - ако така или иначе сте принудени да замените даден метод, защо да губите време за внедряване? Деструкторите са специален случай, защото винаги се извикват дори когато са заменени. - person Mark Ransom; 20.05.2009
comment
Той Х :). Прекарах много твърде много време в отстраняване на грешки, произтичащи от това, че съм забравил да добавя виртуален деструктор към базов клас. - person reuben; 21.05.2009
comment
Марк: Позволява ви да предоставите изпълнение по подразбиране, като същевременно изисква от автора на производния клас да помисли дали трябва да използва изпълнението по подразбиране. Рядко полезни наистина. Но това е стилът, който искате. - person jmucchiello; 21.05.2009

Поне 6 години бях убеден, че всеки проблем има точно 1 решение.

Абсолютно непознаване на множество алгоритми с различна сложност, компромиси пространство/време, ООП срещу функционални срещу императивни, нива на абстракция и неразрешими проблеми. Когато тази блажена наивност се счупи, тя отвори свят от възможности и затръшна вратата на това просто да седнеш и да строиш неща. Отне ми много време, за да разбера как просто да избера един и да бягам с него.

person Community    schedule 07.06.2010

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

Когато започнах да чета за динамични езици и да се опитвам да намеря добър за научаване, четенето за значителното празно пространство на Python ме отблъсна - бях убеден, че ще мразя това. Но когато в крайна сметка научих Python, той стана нещо, което наистина харесвам. Обикновено полагаме усилия на който и да е език да имаме последователни нива на отстъп, но не получаваме нищо в замяна (освен визуалната четливост). В Python открих, че не полагам повече усилия от преди по отношение на нивата на отстъпи и Python се справи с това, за което трябваше да използвам скоби или каквото и да било в други езици. Сега Python ми се струва по-чист.

person Community    schedule 20.05.2009

Добър ден,

Че просто ще проектирам и пиша код.

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

наздраве,

person Community    schedule 19.06.2009
comment
За щастие всичко това беше пробито в мен в университета! Иначе щях да преживея шока на живота си ;-) - person Barry Gallagher; 19.06.2009
comment
А... причината номер 1, поради която получих дипломата си по ИТ, след което направо се записах в правоприлагащите органи. (по ирония на съдбата, сега съм ченге, назначено за ИТ проект, събирам изисквания, документация и връзка между потребители и доставчици.) ​​=P - person Darkwoof; 16.06.2010

  • Моите колеги създаваха/произвеждат уж лош код, защото бяха гадни/гадни. Отне ми известно време, за да науча, че първо трябва да проверя какво наистина се е случило. В повечето случаи лошият код беше причинен от липса на управление, клиенти, които не искаха да проверят какво наистина искат и започнаха да променят мнението си, сякаш няма утре, или други обстоятелства извън ничий контрол, като икономическа криза.
  • Клиентите изискват функции "за вчера", защото са глупави: Не съвсем. Става дума за комуникация. Ако някой им каже, че всичко наистина може да се направи за 1 седмица, познайте какво? ще го искат след 1 седмица.
  • „Никога не променяйте кода, който работи“. Това не е хубаво нещо IMO. Очевидно не е нужно да променяте това, което наистина работи. Въпреки това, ако никога не промените част от кода, защото се предполага, че работи и е твърде сложен за промяна, може да се окаже, че кодът всъщност не прави това, което трябва да прави. Например: Виждал съм софтуер за изчисляване на комисионна за продажби, който прави грешни изчисления в продължение на две години, защото никой не иска да поддържа софтуера. Никой от продажбите не знаеше за това. Формулата беше толкова сложна, че всъщност не знаеха как да проверят числата.
person Community    schedule 19.06.2009

никога преди не съм срещал целочислена промоция... и мислех, че 'z' ще съдържа 255 в този код:

unsigned char x = 1;
unsigned char y = 2;
unsigned char z = abs(x - y);

правилната стойност на z е 1

person Community    schedule 20.05.2009
comment
В зависимост от изпълнението, z може да бъде 65535. Или различни други стойности. - person Windows programmer; 08.06.2009
comment
не, не можеше. описаното поведение е правилно според стандарта. знаете ли компилатор, който действа така, както сте описали? - person Andrey; 08.06.2009
comment
Стандартът позволява съответстваща реализация да дефинира unsigned char (и обикновен char и signed char) като 16 бита и да дефинира int (и unsigned int) като 16 бита. Няма значение дали познавам компилатор, който дефинира char като 16 бита. Няма значение дали съм използвал компилатори, които дефинират int като 16 бита. Стандартът го позволява. - person Windows programmer; 08.06.2009
comment
sizeof(char) не е важен в този случай, защото поради повишение, даденият израз, който се предава като аргумент на abs, става (int)x - (int)y, а abs(-1) винаги ще бъде 1. - person Andrey; 08.06.2009
comment
Разбира се, sizeof(char) не е важен. sizeof(char) винаги е 1. Междувременно стандартът позволява подходяща реализация да дефинира unsigned char като 16 бита и unsigned int като 16 бита. В тази реализация, напълно законно, x е 1, y е 2, тъй като изваждането x повишава до unsigned int със стойност 1, y повишава до unsigned int със стойност 2, резултатът от изваждането е 65535 и abs(65535) е 65535. В тази реализация стандартът изисква unsigned char да се повиши до unsigned int, тъй като обикновеният (подписан) int не може да съдържа всички стойности, които може да съдържа unsigned char. - person Windows programmer; 09.06.2009
comment
Току-що разбрах, че Андрей не е знаел, че CHAR_BIT е дефинирана имплементация. 16 е разрешено. - person Windows programmer; 10.06.2009
comment
Разбрах мнението ви; но защо в какъв случай unsigned char ще бъде повишен в unsigned int? това може да се случи само в случай, че int не е в състояние да поддържа стойности на unsigned char. Ако случаят е такъв - тогава abs((int)65535) ще върне 1, защото 65535 ще представлява -1 за int. Ако случаят не е такъв (int е в състояние да задържи unsigned char стойности), тогава повишението ще бъде към int, а не към unsigned int. z пак ще бъде 1. - person Andrey; 10.06.2009
comment
това може да се случи само в случай, че int не може да поддържа стойности на unsigned char -- Бинго, точно както писах по-горе. 16 бита от 16 бита. Благодаря ви, че най-накрая разбрахте. ... z пак ще бъде 1 -- опа, опитайте отново да прочетете какво сте написали няколко реда по-рано. - person Windows programmer; 11.06.2009
comment
Добре, разбирам какво почти каза Андрей. Трябва да знаем кой език за програмиране се използва. Ако е C, тогава abs не е претоварен и аргументът ще бъде понижен от unsigned int към int. - person Windows programmer; 11.06.2009
comment
добре, а ако C++? няма ли да се случи същото в C++? abs има претоварвания за int и long (няма смисъл да има abs претоварвания за unsigned типове) - person Andrey; 11.06.2009
comment
В моя пример с 16-битов char и 16-битов int, когато C++ избере претоварване, което взема вградена промоция от unsigned int, тази вградена промоция ще бъде long, а не int. Plain int може да загуби някои стойности на unsigned int, но plain long не може. (Отново помнете, това е в моя пример с 16 бита char и 16 бита int. В друг пример, където CHAR_BIT е 64 и int и long са всичките 64 бита, long също ще загуби някои стойности на unsigned int.) - person Windows programmer; 12.06.2009

Съвсем наскоро разбрах, че над един милион инструкции се изпълняват в Hello World! c++ програма, която написах. Никога не бих очаквал толкова много за нещо толкова просто като едно изявление cout

person Community    schedule 21.05.2009
comment
уау ... къде го намери това? - person hasen; 22.05.2009
comment
Леле, оузер! Откъде разбра това? Имате връзки? - person corlettk; 23.05.2009
comment
Правех проучване за проект и използвах pin (pintool.org). Написах малка програма Hello World, за да тествам с техните предварително направени инструменти за броене на инструкции и бях изумен от резултата. - person rzrgenesys187; 25.05.2009
comment
Хм... Току-що компилирах основна програма hello world c++ и имаше 5974 асемблерни линии. - person GameFreak; 10.06.2009
comment
Вместо това опитайте с поставяния. По-малко от 20 инструкции. Поне ако свързвате динамично. :) - person ; 14.02.2011

Това гото е вредно.

Сега ние продължаваме или прекъсваме.

person Community    schedule 20.05.2009
comment
вече не е вярно, защото спряхме да ги използваме! - person mike g; 21.05.2009
comment
Всичко зависи от това как се използват. Компилаторите не използват нищо друго. - person Mike Dunlavey; 21.05.2009
comment
Това е все едно да кажете, че писането на програми в машинен код е добро, защото всички компютри използват машинен код. Goto са вредни, защото насърчават програмистите да създават код, който е труден за четене и отстраняване на грешки. - person Zack; 21.05.2009
comment
@Zack, така че GOTO не са вредни - програмистите са вредни. - person U62; 27.05.2009
comment
@U62 GOTO не са вредни, програмистите, които използват GOTO са вредни. - person Evan Plaice; 15.06.2010

OO не е непременно по-добър от не-OO.

предположих, че ОО винаги е по-добро... след това открих други техники, като функционално програмиране, и разбрах, че ОО не винаги е по-добро.

person Community    schedule 20.05.2009
comment
Приехте, че OO не е непременно по-добро от не-OO и вашето предположение се оказа невярно, т.е. OO е непременно по-добро от не-OO? или сте предположили, че OO е непременно по-добро от не-OO и след това сте научили, че не е непременно по-добро? - person Daniel Daranas; 21.05.2009
comment
Съжалявам, това беше двусмислено. предположих, че ОО винаги е по-добро... след това открих други техники, като функционално програмиране, и разбрах, че ОО не винаги е по-добро. - person sean riley; 22.05.2009
comment
Благодаря за уточнението - така си го представях, но исках да чуя точните ви мисли! - person Daniel Daranas; 23.05.2009

не използвайте разширени функции, специфични за изпълнението, защото може да искате да превключите внедряването „някога“. Правил съм това многократно и почти неизменно промяната никога не се е случвала.

person Community    schedule 23.05.2009

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

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

Няма такова нещо като твърде много сложност или абстракция

Отговорност от един клас – никога не съм имал тази концепция, тя беше много възпитаваща за мен

Тестването е нещо, което не е необходимо да правя, когато кодирам в спалнята си

Нямам нужда от контрол на източника, защото е излишно за проектите, които правя

Разработчиците правят всичко, ние трябва да знаем как да проектираме икони и да правим страхотно изглеждащи оформления

Dispose не винаги се нуждае от финализатор

Трябва да се хвърля изключение всеки път, когато възникне някакъв вид грешка

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

Написах приложение, което няма никакви грешки

person Community    schedule 27.05.2009
comment
Това са хубави уроци, но... Кое от тези предположения се оказа невярно? - person Windows programmer; 08.06.2009
comment
Наскоро научих: GIT е невероятно и си помислих същото. Също така уча тестове (различни от ръчното тестване... отнема много време). Едно нещо, което може да пропускате-- отстраняване на грешки с помощта на програми за отстраняване на грешки, без разпечатване при различни моменти на изпълнение. (Ако е възможно). Кодирайте без грешки, никога не се опитвайте да напишете надеждна програма, която разчита на външен източник. Единственият ми проблем със супер проста CMS беше, че разчитах на yahoo и f_open, който хостинг деактивира, и yahoo промени крайната точка... - person CodeJoust; 13.10.2009
comment
Ако говорите за .NET, Dispose не винаги се нуждае от финализатор -- това не е погрешно схващане. Всъщност, тъй като SafeHandle беше добавен в .NET 2.0, финализаторите трябва да са доста редки. - person Joe White; 03.02.2011

Че ние като софтуерни инженери можем да разберем какво наистина иска потребителят.

person Community    schedule 11.06.2009

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

В крайна сметка ми хрумна, че има момент, в който повече коментари - без значение колко добре са структурирани - не добавят стойност и всъщност се превръщат в караница за поддържане. Тези дни възприемам подхода на съдържание + бележки под линия и всички са по-щастливи за това.

person Community    schedule 17.06.2009

Че единственият проблем с локализацията/интернационализацията е преводът на съобщения.

Преди си мислех, че всички други езици (и нямах понятие от локали) са като английския във всички отношения, с изключение на думите и граматиката. Следователно, за да локализирате/интернационализирате част от софтуера, трябва само да имате преводач, който да преведе низовете, които се показват на потребителя. Тогава започнах да осъзнавам:

  • Някои езици се пишат отдясно наляво.
  • Някои скриптове използват контекстно оформяне.
  • Има голямо разнообразие в начина, по който са форматирани датите, часовете, числата и т.н.
  • Програмните икони и графики могат да бъдат безсмислени или обидни за някои групи хора.
  • Някои езици имат повече от една „форма за множествено число“.
  • ...

Дори днес понякога чета за проблеми с интернационализацията, които ме изненадват.

person Community    schedule 19.12.2010
comment
+1 . Веднъж ме хванаха за проблема с формата за множествено число. Напълно ме изненада. - person EightyOne Unite; 20.12.2010

Преди си мислех, че кутия модел на Internet Explorer 6 е зла тъпа идея, която MS излезе само за нарушаване на съвместимостта с други браузъри.

Много CSS-ове ме убедиха, че е много по-логично и може да направи поддръжката на дизайна на страницата (промяна на подложки/граници/маржове) много по-лесна.

Помислете за физическия свят: промяната на подложките или ширината на границите на A4 страница не променя ширината на страницата, а само намалява пространството за съдържанието.

person Community    schedule 24.06.2010
comment
Може да има логическа основа, но все пак противоречи на CSS спецификацията и следователно е грешка. - person Kevin Wright; 04.07.2010

  • Език за програмиране == Компилатор/Интерпретатор
  • Език за програмиране == IDE
  • Език за програмиране == Стандартна библиотека
person Community    schedule 20.05.2009

Мислех, че съм доста добър програмист. Заема тази позиция в продължение на 2 години.

Когато работиш във вакуум, лесно се пълни стаята :-D

person Community    schedule 21.05.2009

Че популярният сега знак $ е незаконен като част от идентификатор на java/javascript.

person Community    schedule 21.05.2009
comment
Погледнете Perl и PHP, тогава наистина ви се иска да е незаконно ;) - person Frank; 08.07.2010
comment
@Frank Иска ми се Perl и PHP да са незаконни. По закон. - person ; 14.02.2011

Мисля, че знам всичко за определен език / тема в програмирането. Просто не е възможно.

person Community    schedule 21.05.2009

Че архитектурите на виртуални машини като Java и .NET по същество са безполезни за нищо друго освен за проекти за играчки поради проблеми с производителността.

(Е, за да бъда честен, може би това е вярно в даден момент.)

person Community    schedule 21.05.2009
comment
Този мит продължава да съществува и до днес. Контрааргумент: cplus.about.com/od/programmingchallenges/a/challenge12.htm java 0,02688359274 секунди; C# 0,166 секунди; C++ 429.46 секунди; forums.sun.com/thread.jspa?messageID=10435068#10435068 1-во и 2-ро са и двете VM, така че не казвайте, че C++ е присъщо по-бърз или по-бавен. Лошият майстор обвинява инструментите си. Най-добрите цигулки са направени, преди да знаем как да измерваме нещо с достатъчна прецизност, за да го възпроизведем. Освен: Боб Уилсън за квантовата физика: videosift.com/video/ - person corlettk; 23.05.2009
comment
Само за заяждане, но .Net не е виртуална машина. Това е компилатор точно навреме, така че IL се компилира до собствен машинен код веднъж за всяко внедряване. - person Joel Coehoorn; 04.06.2009
comment
Вярно е, че използва JIT, но използването на .NET се чувства същото като дизайн на VM в стил Java (и разбира се, Java също има JIT). - person Qwertie; 09.07.2010

Този C++ беше най-готиният език!

person Community    schedule 22.05.2009
comment
Разбира се, че е. не знаеш ли - person jrharshath; 27.05.2009
comment
Да, така си мислех и дори спорех за това. - person hasen; 27.05.2009
comment
Какво не е наред с C++? Искам да кажа, знам, че има неща, които не са наред с него, но е доста готино. Бих се застъпил за това. - person Carson Myers; 02.06.2009
comment
Определено не е най-готиното - person hasen; 02.06.2009
comment
Не е най-готиният? Можете да правите ООП и метапрограмиране по ефективен начин! - person pyon; 31.08.2009
comment
Беше готино... сега е за съжаление старо и неИЗЪХНАЛО :(. Разбира се, разбира се, все още е най-доброто за ефективен код, но не толкова готино. Метапрограмиране? Имате предвид Template Black Magic Trickery that Halts Compilers? Python е новото готино дете наоколо... разбира се, това е малко бавно дете... но готино. Както и да е, C++ преминава през някои операции, за да излезе като новия C++0x... опа, C++1x хлапе. Тогава отново ще бъде готино, все едно 60-годишен мъж се облича като 15-годишен тийнейджър! - person e.tadeu; 10.02.2010
comment
-1. Шаблонното мета програмиране в C++ е най-якото нещо, което съществува. - person Viktor Sehr; 16.05.2010

Важно е да се абонирате за много RSS канали, да четете много блогове и да участвате в проекти с отворен код.

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

Рег. отворен код, опасявам се, че няма да бъда популярен. Опитах се да участвам в отворен код и повечето от тях в .NET. Ужасен съм да видя, че много проекти с отворен код дори не следват подходяща архитектура. Видях една система в .NET, която не използва многослойна архитектура, и кодът за връзка с базата данни беше там навсякъде, включително кода отзад, и се отказах.

person Community    schedule 25.05.2009

Че мениджърите знаят какво говорят.

person Community    schedule 28.05.2009

Че образованието ми ще ме подготви за работа в областта.

person Community    schedule 12.10.2009

Че изучаването на езика е просто изучаване на синтаксиса и най-често срещаните части от стандартната библиотека.

person Community    schedule 03.04.2010

Тези байткод интерпретирани езици (като C# или F#) са по-бавни от тези за нулиране с бутони, които компилират директно в машинен код.

Е, когато започнах да вярвам в това (през 80-те), беше истина. Въпреки това, дори в C# - понякога се чудех дали "поставянето на този вътрешен цикъл в .cpp - файл ще направи приложението ми по-бързо").

За щастие не.

За съжаление разбрах това едва преди няколко години.

person Community    schedule 12.07.2010
comment
Ето още нещо: C# не е език, интерпретиран с байт код. Има аналог на байт код в IL, но C# IL се компилира предварително до напълно естествен код, преди вашата програма да започне да работи. - person Joel Coehoorn; 12.07.2010
comment
Това е само част от това, което имах предвид. Моето убеждение беше, че JIT е много по-нисък от директно компилирания код, което е грешно. - person Turing Complete; 13.07.2010

„Този ​​път ще се получи“

person Community    schedule 23.03.2011

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

person Community    schedule 20.05.2009

че след като завърша CS училище, мога да започна работа и да използвам знанията си, които съм научил в училище, за приложения в реалния свят. (Всъщност ми се иска да не губя 4 години от живота си в изучаване на операционни системи и пролог)

person Community    schedule 20.05.2009
comment
Тъжното е, че (поне за мен) операционните системи, прологът и подобни теми (особено AI и 3D графики) бяха забавни. Вероятно щях да избера друга кариера, ако знаех, че реалният свят е много по-обикновен. - person Cybis; 21.05.2009
comment
съгласен. Изглежда, че повечето от нас се забиват в правенето на уеб приложения и сравнително проста работа с база данни, след като са изучавали някаква твърда разработка на C/C++. - person jDeveloper; 21.05.2009
comment
От друга страна, обратното е също толкова вярно: че мога да създавам приложения от реалния свят (добре), без да разбирам основите като операционни системи и пролог - намирам това за много често сред лошите програмисти, които срещам... - person AviD; 28.08.2009

Бих могъл да прекарам дни в опити да намаля количеството памет, използвано от моя бизнес слой, само за да разбера по-късно, че WinForms (GUI) на моя проект използва 4 пъти повече памет от останалата част от приложението.

person Community    schedule 20.05.2009

Дълго време (около 5 години) си мислех, че PHP е страхотен.

Мислех, че знам алгоритми. И тогава се присъединих към Topcoder.com

person Community    schedule 21.05.2009
comment
Да, бил съм там. Странно е колко очевидна става тази грешка, след като научите за това малко нещо, наречено пространства от имена. - person Evan Plaice; 15.06.2010
comment
PHP скали. Рубинени хартии. Хартията побеждава скалата. - person ; 14.02.2011

Побитовите сравнения на цели числа в SQL WHERE клаузите са практически безплатни по отношение на производителността на заявките.

Както се случва, това е донякъде вярно за първите половин милион реда или така. След това се оказва, че е изключително без ООН.

person Community    schedule 21.05.2009
comment
Без ООН == скъпо? Дали това е скрито политическо изявление за ООН? Страхотни. - person Kieveli; 21.05.2009
comment
Моля, за коя RDBMS се отнася това? Никога не съм имал проблем с Access, Sequal, Ingres, Postgres, Informix или MySql... въпреки че (съзнателно) съм се занимавал само с многомилионни таблици с редове в Ingres и Informix. - person corlettk; 23.05.2009
comment
В моя случай SQL Server, но мисля, че ще се прилага за всяка RDBMS. Проблемът е, че побитовите операции не могат да се обработват и няма да използват индексите ефективно. Операцията обаче е толкова бърза дори при сканиране на маса, че не го забелязах, докато не стана наистина голям. - person JohnFx; 23.05.2009
comment
DB върви бързо през първия половин милион и след това се забавя? - person Qwertie; 09.07.2010
comment
Просто казвам, че профилът на ефективност прилича на O(N) - person JohnFx; 09.07.2010

Този ASCII е съхранен по различен от двоичния начин

person Community    schedule 21.05.2009
comment
Какво?! Това е... ASCII е символен код, двоичният е начин за писане на числа... - person Zifre; 22.05.2009
comment
Имах предвид, че все пак изображение и текстов файл се съхраняват по различен начин на диска. Че изображението е двоично, а текстът е нещо друго. - person ; 22.05.2009
comment
В това има частица истина. няколко файлови системи, особено мрежовите файлови системи, обработват байтовете, съответстващи на нови редове, по различен начин в зависимост от това дали смятат, че файлът е текстов или нетекстов. По-специално, някои направиха много трудно коригирането на това, когато се случи да е грешно. Малко нови технологии правят това, защото идеята е ужасна. - person SingleNegationElimination; 22.05.2009
comment
(Open)VMS например го прави, така че технически не е съвсем погрешно. И причината, поради която C поддържа и двата файлови режима. - person MSalters; 31.08.2009
comment
Всъщност, когато започнах да програмирам C, вярвах, че различните режими се дължат на забавянето на DOS. Е, като си на 10 години получаваш всякакви луди идеи ;) - person Frank; 21.02.2011

В първите дни повечето персонални компютри имаха интерфейс за касета за зареждане и съхраняване на програми. По това време нямах компютър, но четях всичко, до което можех да се добера (предимно списания), което имаше нещо общо с компютрите (това беше края на 70-те години - нямаше интернет за мен). По някаква причина останах с впечатлението, че програмите се изпълняват директно от касетата и че единствената причина компютрите да имат RAM е да съхраняват променливи, докато програмата работи. Реших, че когато кодът трябваше да изпълни инструкция за прескачане, той по някакъв начин щеше да превърти назад или да придвижи напред лентата до правилната позиция и да продължи оттам.

person Community    schedule 22.05.2009
comment
Все още, до ден днешен, не успях да обясня адекватно разликата между енергонезависима памет (RAM) и енергонезависима памет (твърд диск и т.н.) на майка ми. - person Dan Diplo; 29.07.2009
comment
Трябва да го харесам... Удивително как се промениха нещата... този байт код на касетите ли беше? Там няма езици на високо ниво. - person CodeJoust; 13.10.2009

Че всички останали използват най-новата и най-добрата технология, докато моят екип е единственият, заседнал с по-лоши остарели инструменти. (С изключение на мистичните кобол динозаври)

person Community    schedule 22.05.2009
comment
Бъдете добри с динозаврите COBOL. Аз контролирам банковата ви сметка ;-) - person corlettk; 23.05.2009

Че всеки иска да произведе възможно най-добрия\най-подходящ код за проблем...

person Community    schedule 22.05.2009

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

person Community    schedule 23.05.2009

Че хората ще се интересуват от най-добрите практики или дори последователността.

person Community    schedule 19.06.2009


Че трябва да дефинирам всички променливи, които ще използвам в моята функция в нейното начало (стил Pascal).

Вярвах, че трябва да помисля за ВСИЧКИ ресурси, които да бъдат използвани от моята функция, и да ги дефинирам, преди да започна да кодирам, вероятно защото първият ми език беше Pascal, където това е изискването. След това, когато преминах към C, щях да дефинирам временни променливи, които се използват само в рамките на цикли извън тези цикли, пренебрегвайки обхвата в цикъла, само така че "всичко да бъде дефинирано в началото".

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

person Community    schedule 28.08.2009

Когато чух за първи път, мислех, че „патешко писане“ всъщност е „патешко писане“, подобно на начина, по който хората често казват патешка лента. „Патешко писане“ просто звучеше погрешно, докато „канално писане“ имаше странен смисъл (сглобени типове).

person Community    schedule 03.04.2010
comment
Чакай, това не е тиксо? Мога ли да го използвам и върху гъски? - person Don Branson; 12.07.2010
comment
Някак ме кара да се чудя защо не е писане по канал - изглежда много подходящо! - person Kevin Wright; 13.07.2010
comment
@Evan Plaice typedef tape ducttape; - person ; 14.02.2011

Че програмирането е за младши и че най-добрите ръководители на проекти са хора, които не могат да програмират.

person Community    schedule 17.04.2010

Че процедурните разработчици/програмисти, които не са запознати с SQL и релационни бази данни, не се нуждаят от официално обучение или разбиране как да работят с и/или използват SQL и че бързото четене на нещо като SQL For Dummies е достатъчно, за да са достатъчни при работа с релационни бази данни като Oracle & SQL Server.

Твърде често много грешки в приложения, работещи с данни, съхранявани в релационни бази данни като Oracle и SQL Server, са причинени от липса на разбиране или как да се използва езикът на релационните бази данни; SQL.

Работех за доставчик на софтуер, който имаше манталитета, че всичко, от което един разработчик се нуждае, е книгата SQL For Dummies или нещо подобно и те ще бъдат напълно оборудвани да се справят с всеки проблем с релационна база данни. Сега, когато клиентите на този доставчик имат бази данни, измерващи се в стотици гигабайти, тази липса на познания за SQL се връща по негативен начин. Не само лошо представящите се търсения и/или актуализации и вмъквания са проблем, но действителният дизайн на самата база данни е истинската пречка.

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

Не отхвърляйте SQL като маловажен, защото той ЩЕ се върне да ви преследва в крайна сметка. Може да успеете да се измъкнете от това за известно време, дори години, но в крайна сметка ще достигнете точката на пречупване, в която не можете да напреднете без цялостен редизайн на вашата база данни и тогава разходите ще бъдат най-високи.

person Community    schedule 12.07.2010

Че никога не завършваш проекта, който не си започнал.

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

person Community    schedule 14.06.2010

Че винаги има "правилен" начин да се правят нещата. Твърде дълго се придържах към това предположение, след като напуснах университета.

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

person Community    schedule 03.02.2011

В началото на моите C++ дни (преди доста време) бях заобиколен от Java академици. Когато ме попитаха за предимството на C++ пред Java (обикновено въпрос, който се опитвам да отхвърля като измислен, но ето го), бих включил в отговора си, че C++ ви дава препратки и указатели. Момчетата от Java биха изглеждали недоверчиви и биха предположили, че препратките са указатели, и ме изкараха със смях от стаята. Настоях, че препратките и указателите са различни в C++.

И за да бъда честен, бях прав. Препратките и указателите са различни семантично и синтактично. За съжаление, подкрепих твърдението си с една заблуда: че основната реализация е различна.

Твърдото ми убеждение беше, че референциите са, според стандартизацията, псевдоними на имена в синтаксиса по същия начин, по който typedef е псевдоним на тип без съхранение.

Бях сигурен, че референциите не са обекти и нямат място за съхранение, че те просто предоставят множество съпоставяния от най-високо ниво на „име“ към „обект“. В това отношение си помислих, че те са като меки връзки във файлова система:

Code: int a = 3; int& b = a;

 Names          Objects           Memory

+-----+     +-------------+     +-------+
|  a  |---->|             |     |       |
+-----+     |             |     |       |
            |     int     |---->|   3   |
+-----+     |             |     |       |
|  b  |---->|             |     |       |
+-----+     +-------------+     +-------+

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

Достатъчно е да кажа, че бях разочарован да науча, че компилатор с изключени оптимизации може да имплементира препратка като указател, изискващ операция за дерефериране: че всъщност създавах аналогията с твърда връзка в файлова система:

Code: int a = 3; int& b = a;

 Names          Objects           Memory

+-----+     +-------------+     +-------+
|  a  |---->|     int     |---->|       |
+-----+     +-------------+     |       |
                                |   3   |
+-----+     +-------------+     |       |
|  b  |---->|     int&    |---->|       |
+-----+     +-------------+     +-------+

Стандартният C++ всъщност не уточнява как референциите трябва да бъдат реализирани, така че моята теория може да е вярна за някои вериги от инструменти, но не е в нито един масов компилатор... и със сигурност не е посочено в стандарта.

person Community    schedule 23.03.2011

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

person Community    schedule 20.05.2009

От дните на колежа смятах, че съм майстор на програмирането. тъй като аз можех да кодирам, но другите не можеха. Но когато се присъединих към компания, бях поразен от невежеството си относно основите. Всичките ми предположения за себе си се оказаха грешни! Сега знам какво трябва да знам и какво не знам!

person Community    schedule 21.05.2009

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

Но с повече опит не става въпрос за байтове или за цикли на процесора, а за вашия поток от мисли, непрекъснат, непрекъснат, много като стихотворение.

По същество не се опитвайте твърде много.

person Community    schedule 21.05.2009
comment
› Не се притеснявайте за малките неща! ~~ анон. - person corlettk; 23.05.2009
comment
Аз правя същото! Е, само евентуално, защо не мога да оптимизирам/комбинирам тази SQL заявка... (за тест, който получава 5 показвания на страници на месец :) ). - person CodeJoust; 13.10.2009

Когато бяха в колежа (средата на 90-те) имаха само машини с Windows 3.11 в компютърната лаборатория (знам, странен колеж).

Известно време си мислех, че само платформата Windows е подходяща за мен като професионален програмист и че всички други платформи са интересни само от историческа академична гледна точка.

След като завърших училище и научих за съвременните Unix и Linux среди, не можех да не се чувствам ядосан и разочарован от моето куцо училище.

Все още не мога да повярвам, че съм завършил компютърно инженерство, без изобщо да съм виждал bash shell или дори да съм чувал за emacs или vim.

person Community    schedule 21.05.2009
comment
Това е... впечатляващо, е почти единствената дума, за която се сещам. - person mavnn; 21.05.2009
comment
Имах късмет... Имахме система xenix (ранен Microsoft Unix порт към Intel) в моя колеж TAFE. Трябваше да играя и един от приятелите ми беше назначен отново като системен администратор... и го измислихме заедно. Когато започнах работа по Solaris, бях много по-напред от моите сънародници. Да, университетска среда само за Windows е напълно гадна. - person corlettk; 23.05.2009
comment
Кой все пак използва Unix? Поне това си мислех, когато бях ПРИНУДЕН да науча САМО Unix в uni, като основно третирах не-Unix среди като играчки за дома (прозорци) или несъществуващо наследство (мейнфрейми и т.н.). - person AviD; 28.08.2009

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

Работех с мой клиент, който ме привлече най-вече като поддръжка и да напиша някои от по-сложните неща за него. Ами един ден той обърка досие, голямо време. Той случайно запази повече от три часа от собствената си работа и когато го попитах защо не запазва по-често, той отговори с „защото не съм свършил“. Естествено, това не беше приемлив отговор и аз бръкнах и побутнах още малко. В крайна сметка разбрах, че той никога не е използвал програма за редактиране, НИКОГА! Нито дори notepad.exe! Той използваше онлайн редактор на CPanel за файлове! Дори нямаше функция „Намери“. Той никога не можеше да запази, докато не свърши, защото редактираше живия файл на сайта!

Излишно е да казвам, че бях поразен и той все още използва редактора на CPanel до ден днешен...

person Community    schedule 22.05.2009
comment
Редактор на Cpanel! Cpanel е добро управление, но сериозно... Използвам го само за корекции на пътя... Никога не се доверявайте на отдалечен сървър, понякога просто копирам дълъг коментар в клипборда, за да не се притеснявам, ако не публикува... (за много неща онлайн като убийствени сесии, когато имате добър, дълъг коментар или публикация и т.н.) - person CodeJoust; 13.10.2009
comment
За бързи корекции, признавам, че съм правил това. - person Macha; 04.04.2010

Изучаването на регулярни изрази ще ви спести време

person Community    schedule 22.05.2009
comment
наистина ли? Не са ви спестили време? Те ми спестяват много работа всеки ден. - person Demi; 22.05.2009
comment
хаха Има само два вида регулярен израз /сложен/ && /сложен далеч/. - person corlettk; 23.05.2009
comment
LOL @ това, това ми напомня за цитата: Някои хора, когато се сблъскат с проблем, си мислят, че знам, ще използвам регулярни изрази. Сега имат два проблема. Благодаря Джеф :D - person Leo Jweda; 07.06.2009
comment
Ще го направят, ако не прекалявате с тях. Познаването на основите ми спести много време! (Опитайте да направите 4 верижни str_replace подред...). - person CodeJoust; 13.10.2009

Моето най-дълго задържано (и следователно най-скъпо) неправилно предположение беше: „Изискванията на бизнеса са разумни и разумни, просто все още не ги разбирам.“

100 зелени предположения, разположени на стената,
и ако случайно падне едно зелено предположение,
на стената ще има 99 зелени предположения.

Алтернативно:

Хъмпти Дъмпти седеше на стената.
Хъмпти Дъмпти падна страхотно
и всички крале коне и всички крале мъже,
каза Ефим, той е само техник.

person Community    schedule 23.05.2009

Че като изучавам точна наука, няма да имам нужда да подобрявам ограничените си социални умения.

person Community    schedule 23.05.2009
comment
софтуерното инженерство обаче не е точна наука - person wds; 27.05.2009

Че редът на оценка на операторите if в C/C++ е специфичен за компилатора. Така че писане:

if ( pointer != NULL ) && ( pointer->doSomething() )

Беше опасно, защото редът за оценка можеше да бъде разменен. Наскоро разбрах (след много години бълване на тази лъжа), че е част от спецификацията ANSI-C, можете да гарантирате поръчката и тя е напълно безопасна.

Джеймс

person Community    schedule 10.06.2009
comment
stackoverflow.com/questions/888224/ - person Michael Myers; 10.06.2009
comment
mmyers, ти спомена точно този въпрос, на който отговорът на този отговарящ отговори почти перфектно. Забравихте ли да добавите още нещо? - person Windows programmer; 12.06.2009
comment
Междувременно оценката на повечето изрази, включително изрази в операторите if, често може да бъде специфична за компилатора. Изразът if на Джеймс Норис съдържа три оператора. Две от трите не налагат никакъв ред. - person Windows programmer; 12.06.2009
comment
Да, не забелязах предишната точка, благодаря! Ако погледнете под условни оператори в спецификацията на ANSI C: std. dkuug.dk/JTC1/SC22/WG14/www/docs/n843.pdf 6.5.13 Логически оператор И ... За разлика от побитовия двоичен оператор &, операторът && гарантира оценка отляво надясно; има точка на последователност след оценката на първия операнд. Ако първият операнд в сравнение е равен на 0, вторият операнд не се оценява. Освен това: Трудно ми е да повярвам, че езици като C++/Java, създадени след C спецификацията, също не следват това правило. - person ; 12.06.2009
comment
Не знам за език, който да не използва късо съединение и/или логика. Е, добре, VB. Но изглежда, че разчитам на късо съединение и/или логика почти всеки ден. Трудно ми е да си представя как би изглеждал кодът ми, ако не знаех този основен принцип. - person Qwertie; 09.07.2010

Че някога ще стана богат софтуер за програмиране за някой друг

person Community    schedule 10.06.2009
comment
Има дни, в които си мислех същото - person Viktor Sehr; 09.07.2009

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

Обикновено това е или „четене от потребител, запис в база данни“ или „четене от база данни, показване на екрана“. Тези два случая покриват около 95% от работата, която някога ще свършите.

person Community    schedule 19.06.2009
comment
Бих гласувал за това, но технически не е правилно. Разбирам какво имате предвид, но в действителност все още има много обработка. - person DoctorFoo; 19.06.2009
comment
Хм, кодът ми обработва данни постоянно и по много начини... - person Qwertie; 09.07.2010

Удовлетворете клиента, като внедрите това, което той иска - за съжаление това означава, че клиентът знае какво иска.

person Community    schedule 19.06.2009

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

person Community    schedule 19.06.2009

Че други хора биха били толкова притеснени от известни грешки, колкото и аз, и биха направили коригирането им приоритет пред работата по проекта.

person Community    schedule 31.08.2009

Че ползата от ООП е, че можете да използвате повторно обекта, когато в действителност това е повторно използване на останалата част от кода чрез създаване на нов обект, който има същия интерфейс .

В действителност обектът може да представлява 2% от кода, така че повторното използване ви носи само 2% полза. Истинската полза е повторното използване на други 98% от кода чрез създаване на нов обект, който позволява на целия друг код да направи нещо напълно различно. Сега имате повторно използване на 98% от кода. Заслужава си 3 пъти по-дълго, за да напишеш нещо като обект.

Например, ако имате програма за рисуване и внезапно се появи нова форма, която искате да можете да рисувате, просто сменете ShapeObject (като запазите интерфейса същия). Нищо друго в програмата не трябва да се променя.

person Community    schedule 13.10.2009

Че няма да има нужда бързо да преработвам своя обектно-ориентиран код. Мартин Фаулър най-накрая ми отвори очите.

person Community    schedule 04.01.2010

Че тестовете са просто още един метод за отлагане.

person Community    schedule 03.04.2010

Този mysql_fetch_row на PHP беше единственият начин за извличане на данни от изпълнена SQL заявка.

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

person Community    schedule 19.06.2010
comment
Напомня ми за C библиотеката за SQLite 3. - person ; 14.02.2011

Че никога няма да намеря практическа употреба в програмирането на картите на Карно, на които ме учеха в моя компютър учебна програма по природни науки.

person Community    schedule 04.01.2010

Че Python беше непрактичен, досаден език (все още мога да прочета някои коментари за моя ранен код, оплакващи се от него), а C++ е единственият истински обектно-ориентиран език.

Толкова грешах, че все още ме е срам.

person Community    schedule 29.07.2009

Научих се на C, като четох K&R. За съжаление не го прочетох дума по дума и сигурно съм пропуснал няколко неща. Написах свои собствени версии на malloc и calloc, които нося със себе си от работа на работа, защото не знаех, че можете просто да се свържете със съществуващи библиотеки. Правих това в продължение на няколко години, докато най-накрая някой ме попита защо разнасям тези неща насам-натам: „хм... осъзнаваш ли, че можеш просто да направиш връзка в съществуващите библиотеки, нали?“

person Community    schedule 23.11.2010

Че всички ООП езици имат една и съща концепция за обектна ориентация.

  • Java interface != интерфейс на метод.
  • Java интерфейсът е специфично за езика решение за необходимостта от множествено наследяване. Миксините на Ruby се опитват да решат същия проблем.
  • Наследяването, предоставено веднага в Javascript, е много различно от начина, по който Java прилага наследяването.
person Community    schedule 20.05.2009

Ако не можете да прочетете кода ми, просто не знаете езика. Имах няколко прегледа на код, където се опитах да се противопоставя на това.

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

person Community    schedule 20.05.2009
comment
Всъщност никога не трябва да бъдете магьосници. Лесно е да напишете код, за да правите това, което искате. Мога да си представя 6-7 начина да направя едно и също нещо. Само няколко от тях са лесни за четене от другите или от вас самите след 6 месеца. Това е истинското предизвикателство. Това е истинската цел на програмирането - да го направи лесно за четене от другите хора. Дори в библиотека други хора ще трябва да я разширят или модифицират. Винаги го дръжте четлив. - person Kieveli; 21.05.2009
comment
Хм, мисля, че тук често има някои компромиси. Понякога малка част от магията на по-нисък слой може да направи много код на по-висок слой едновременно по-малък и по-четлив. Не че никога не трябва да бъдете магически, но трябва да бъдете разумни в прилагането на магията. - person Tagore Smith; 06.12.2010

Че аз програмирам. Изучавайки книгата на SICP, видях, че не знам нищо. Поне сега се задълбочавам повече в програмирането.

person Community    schedule 20.05.2009

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

person Community    schedule 20.05.2009
comment
Добрият програмист е едновременно любим и кодира наистина добре! :Д - person Nicolas Dorier; 21.05.2009
comment
Slashene: Страхотен коментар :-). Но очевидно хората, които се опитват да угодят на мениджъра си, не са по-сериозните в работата си (ти ли?:-) )... И през повечето време, когато се опитват да вършат по-добра работа (с по-малко грешки), отделяте повече време, за да го направите: нещо, с което вашият мениджър винаги няма да е съгласен (дори когато знаете, че ТРЯБВА да го направите). - person yves Baumes; 22.05.2009
comment
какво ще стане, ако вашият мениджър издава странни звуци през цялото време и бъде наистина спокоен с всичките си приятели, които също работят в компанията, и бъде наистина строг и има най-високите очаквания към вас? Приятелите му не трябва да ви отговарят, тъй като знаят, че не могат да бъдат уволнени. Докато от друга страна, вашият мениджър ще ви се обади на мобилния ви телефон, когато има въпрос, очаквайки незабавен отговор. и дори да ви крещи, защото си мисли, че ви плаща и може да ви крещи. - person nonopolarity; 23.05.2009

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

person Community    schedule 20.05.2009

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

person Community    schedule 20.05.2009
comment
Отидете и вижте примерния код в WDK (Windows Driver Kit), по-голямата част от него е част от сборката на Windows и за моите очи е доста ужасен. - person Tony Edgecombe; 21.05.2009

По някакъв начин една компания, която управлява голям брой уебсайтове с доста висок профил/висок трафик, всъщност знаеше какво, по дяволите, правят. В крайна сметка те бяха в по-голямата си част безпомощни и изключително щастливи да бъдат в позицията, в която бяха. Така че предполагам, че моралът би бил,

солидно софтуерно инженерство && най-добри практики != бизнес успех

or....

най-критичните софтуерни системи == глупости

person Community    schedule 21.05.2009
comment
Екземплярът не винаги представлява цялото. Предполагам, че въпросната компания трябва да има много късмет, за да бъде в сегашната си позиция... или те всъщност са параван за американска банка. - person corlettk; 23.05.2009

Не най-дългото задържано, но в някакъв момент и в продължение на няколко години аз:

  • Мислех, че Microsoft Windows е единствената операционна система в света (беше 1992 г.)
  • Познаването на DOS беше повече от достатъчно, за да имате "напреднали" познания за OS.

Ето защо не избрах "компютърен курс" в гимназията. Мислех, че вече знам достатъчно за компютрите.

По-късно в университета и от моя грешка:

  • Мислех, че операционните системи/програмите на UNIX са перфектни и DOS/Windows никога няма да се доближат до тях (тогава изглеждаше толкова вярно, предполагам, че Линус изобщо си е мислил същото и затова Linux е толкова подобен на UNIX, а не. .добре други ОС)

Накрая и за дълго време си помислих, че:

  • Само софтуерът ми е гаден, а комерсиалният софтуер беше безупречен, защото... беше "КОМЕРЦИАЛЕН" софтуер
  • Софтуерът/инженерите/продуктите на САЩ бяха синоними на превъзходство, а всичко отвън беше просто лош опит.
person Community    schedule 21.05.2009
comment
О, сега ти нарани чувствата ми. (Аз съм шведски разработчик. Шегувам се!) - person Andreas Rejbrand; 04.04.2010

Мислех, че Windows 3.1 е само платформа за игра на пасианс. А DOS е платформа за BASICA.

person Community    schedule 22.05.2009

Обработката на грешки е ненужна, когато сте тествали кода си старателно.

person Community    schedule 22.05.2009

Че винаги няма достатъчно време да го завършите преди крайния срок.

person Community    schedule 23.05.2009

Че WTF винаги е доказателство за лош професионалист.

Всъщност напоследък осъзнавам колко WTF-та съм извършил през цялата си кариера, но се успокоих, когато StackOverflow ми показа те са просто още един софтуерен показател.

person Community    schedule 23.05.2009

Тези променливи всъщност са само имена за конкретни области в паметта.

person Community    schedule 23.05.2009

Че създаването на успешно приложение може лесно да се направи само от програмисти. Софтуерът също така е свързан с лекота на използване, добър външен вид, документация и правилен маркетинг. Разработката на софтуер е многодисциплинарна и провалът на една дисциплина вероятно ще провали приложението.

person Community    schedule 25.05.2009

Че език, подходящ за системно програмиране, трябва да поддържа [променливи] променливи.

person Community    schedule 27.05.2009

Често срещани лоши предположения: „Качеството на кода е второстепенно“. Още по-лошо предположение: "Качеството на кода изобщо не е важно."

Качеството на кода може да бъде много широко понятие. Обсъдих го доста подробно тук.

person Community    schedule 28.05.2009

Че колкото повече редове код, толкова по-добър би бил софтуерът.

person Community    schedule 03.06.2009
comment
Уау, това определено не искате. Прекарвам много време в почистване на код. Колкото по-малко линии, толкова по-добре. (и по-ясен синтаксис). - person CodeJoust; 13.10.2009

Че бихте могли да memset( this, 0, sizeof(TheObject) ) C++ обект в неговия конструктор без отрицателни последствия

person Community    schedule 08.06.2009
comment
Ще нулираш vtable! Ако има vtable, мисля, че може да работи само ако има производен клас (който презаписва указателя на vtable, когато неговият конструктор стартира). - person Qwertie; 09.07.2010

Че маркетинговите момчета се интересуват от това, което правите.

person Community    schedule 10.06.2009
comment
Всъщност, тези маркетинг момчета РАЗБИРАТ какво е възможно и какво не, така че не се опитват да продадат решението за глада навсякъде по света. - person pyon; 31.08.2009

Че имате нужда от клиентска спецификация, за да завършите проект. По-често започвате с търговска среща и бележник. Разбира се, в края на срещата те биха искали краен срок, „просто го изпробвайте“.

person Community    schedule 10.06.2009

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

person Community    schedule 19.06.2009

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

person Community    schedule 19.06.2009

  • Мислех, че ще кодирам 8 часа без прекъсване. Реално погледнато, получавам 4 часа на ден за кодиране, 1 час за обяд, 1 за паузи за кафе и 2 за прецакване / бърборене/ подреждане на купчини.

  • Преди да започна работа, си мислех, че всички клиенти ще бъдат идиоти и нямат и две глупости за компютри. Момче, сбърках с това. Понякога получаваме проекти от хора, които могат да го направят по-добре от нас, но те просто нямат време да го направят.

  • Мислех, че кабините са лоши, в момента ги обичам :D Всъщност се преместих от офис с врати към кабина. Харесвам откровеността.

  • Не всички програмисти са атлетични. Мислех, че съм единственият, който ходи на фитнес. Там, където работя, поне 10 от нас ходят на фитнес всеки ден в 5 сутринта.

  • Мислех, че няма да има жени програмисти. Няколко от водещите ни клиенти са дами.

person Community    schedule 19.06.2009
comment
Иска ми се да мога да получа само една жена програмист!, откъде идвам мисля, че е табу, не знам :( - person gath; 19.06.2009
comment
Бих искал да намеря жена програмист, за която да се оженя.. - person Qwertie; 09.07.2010

Че Java предава копия на обекти на функции, а не на препратки.

С други думи, мислех, че ако прехвърлите обект в метод, след това промените обекта по някакъв начин, това не променя обекта в обхвата на извикването. Винаги предавах обекти в методи, манипулирах ги, след което ги връщах!

person Community    schedule 05.07.2009
comment
Това просто ви позволява да().do().this(). :) - person Arafangion; 15.07.2009

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

person Community    schedule 29.07.2009

Това е неудобно, но най-дълго време вярвах, че е по-ефективно за паметта да вложа моите извиквания на метод или да направя множество извиквания на метод, отколкото да създам променлива за съхраняване на стойността за всяко извикване на метод в C#.

person Community    schedule 21.05.2009
comment
Искате да кажете, че е по-ефективно да не се съхраняват междинни резултати във временни променливи? В .NET временните променливи наистина имат малко излишък в сравнение с междинните стойности, но компилаторът често създава временни променливи, без да ги питате за тях, което често ще видите, ако разглобите до CIL. Обикновено не е нужно да създавате обект, за да съхранявате резултата от метод; Предполагам, че имате предвид променлива. - person Qwertie; 09.07.2010
comment
@Qwertie: Благодаря. Актуализирах отговора, за да чета по-ясно. - person Alexander Kahoun; 12.07.2010
comment
Компилаторът не оптимизира ли това? - person ; 14.02.2011

Тази простота почти винаги побеждава сложността. KISS - Keep It Simple Глупави правила.

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

person Community    schedule 12.07.2010
comment
Може да сте прочели въпроса погрешно. Според заглавието звучи така, сякаш вярата в простотията се оказа невярна? - person Georg Fritzsche; 12.07.2010
comment
Всъщност бих се съгласил с това. Най-добрият и най-бързият софтуер в света е невероятно сложен и се появи там с причина. - person Andres Jaan Tack; 12.07.2010
comment
Съжалявам, трябва да съм загубил въпроса, след като прочетох твърде много отговори. Но ваше право, трябваше да кажа, че сложността е по-добра от простотата. Това означава, че простотата обикновено е най-добрият начин, когато програмирате. Той е по-лесен за поддръжка, по-лесен за отстраняване на грешки и понякога дори работи по-бързо. - person mwgriffith; 12.07.2010

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

person Community    schedule 12.07.2010
comment
Клиентите ми искаха документиран доклад за неуспешни тестове. Като просто казах, че съм тествал това и работи, ги изплаших до дяволите. - person Buhake Sindi; 13.07.2010

Че мога да убедя традиционните процедурни програмисти защо ООП често предоставя по-добро решение.

Тоест езикът, който описва света, се нуждае от способността да описва сложни обекти и техните взаимоотношения.

Аргументите обикновено включваха глупости за абстрактни класове, на които аз отговарях с „не всички ООП програмисти са току-що излезли от Университета и все още са обсебени от абстрактите“. Или класическото „няма нищо, което бихте могли да направите в ООП, което аз да не мога да направя със строго процедурно програмиране“, на което обикновено отговарях с „Не че можете, а дали бихте, ако разполагате с по-обширен набор от инструменти".

Научих се просто да приемам, че те не виждат света през същата призма, както аз.

person Community    schedule 14.06.2010
comment
Традиционните процедурни програмисти имат различен поглед върху живота. За тях компютърът използва програма за обработка на данни. Вход-›Програма-›Изход. Заплитането на данни с процедури не добавя стойност. С други думи, в мисленето на традиционния програмист, програмата дори не се опитва да опише сложни обекти и техните взаимоотношения. Не прави модел на нищо. Използва алгоритми, които четат вход и записват изход. - person Erich Kitzmueller; 11.08.2010

че временните решения не са постоянни решения
или с други думи: заобиколните решения не са завинаги :)).

person Community    schedule 11.08.2010
comment
Това го казваш! Не искам да знам колко от моите решения все още се носят наоколо... - person Bobby; 11.08.2010
comment
добре да, затова е грешно това, което казвам, нали? мисълта ми е, че заобиколните решения са завинаги, светът просто изобщо не е идеален... - person ; 11.08.2010

Че софтуерните инженери винаги са честни за това, което правят сега или какво са правили с вашия софтуер в миналото.

person Community    schedule 20.05.2009

Тези 640K трябва да са достатъчни за всеки (DOS). В това се вярваше много хора в продължение на няколко години.

Първият път, когато имах система с 8 MB RAM, си помислих, че това е много повече, отколкото ми трябва. Това стартира операционната система (Mac) плюс всички приложения, които използвах (Word, Email, Firefox и т.н.).

person Community    schedule 20.05.2009
comment
Пускали сте firefox на 8MB машина? Кое десетилетие беше това и как се сдобихте с толкова ранно копие ;) (преднамерен sarcarm) - person Evert; 20.05.2009
comment
Как е свързано това програмиране с предположения? Използвахте ли Word, Email (това реално приложение ли е?) и Firefox за програмиране? - person bzlm; 20.05.2009
comment
Изявлението му беше за използването на паметта от програмиране... докато примерите не бяха. Не виждам защо това беше отхвърлено. - person Matthew Whited; 20.05.2009
comment
Пич, тогава нямаше firefox. и думата вероятно беше бележник, хаха. - person hasen; 23.05.2009
comment
Прав си, беше Mosaic (NCSA?). Всъщност исках да кажа FoxBase, а не Firefox. И имаше програма, наречена Mail, която Microsoft купи. Те също купиха Fox Software, производители на Foxbase. - person Brent Baisley; 24.05.2009
comment
@Brent Baisley: тогава защо не редактирате отговора си? - person Cristian Ciupitu; 25.06.2010

Че нишките в Windows са евтини.

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

person Community    schedule 20.05.2009

Че всичко, което написах, ще се провали в един момент в обозримо бъдеще.

Не че всичко в крайна сметка няма да се разпадне, но в началото на обучението ми по програмиране, когато открих блокове try..catch... опаковах ВСИЧКО в тях... неща, които, ако се провалиха, щяха да представляват много по-големи проблеми, с които моите програми биха се справили (напр. северният и южният полюс са разменили местата си)

person Community    schedule 20.05.2009
comment
Любимият ми бъг: Очевидно първият път, когато F111 прелетя над екватора в режим на следване на терена (500 фута над океана на около мах 1), той се обърна... това е единственият начин софтуерът да разбере наляво и надясно при отрицателна ширина. Опа! - person corlettk; 23.05.2009

Че изучаването на изцяло нов език би било наистина много трудно.

person Community    schedule 21.05.2009
comment
трудно е изучаването на стандартната библиотека. - person GameFreak; 10.06.2009

Това представяне по време на изпълнение имаше значение. Общото време за решение често е това, което има значение.

Откакто научих Python, се отучих от привързаността си към статичното писане.

person Community    schedule 21.05.2009
comment
Опитвал съм Python преди, но, вярвате или не, пиша повече грешки в Python, отколкото в C++ (и нямам много опит с C++). Статичното писане е много по-продуктивно. - person Zifre; 22.05.2009
comment
@Zifre: има известна истина, но също така има значение колко бързо можете да ги поправите и колко бързо можете да напишете цялата програма. Имах своя дял от грешки, причинени от динамично писане, но тъй като бяха лесни за коригиране, не ме притесняваха много. - person Cristian Ciupitu; 25.06.2010

Не знаех, че нещо разделено на 0 в Javascript е Infinity (IEEE 754 аритметика). Научих го по трудния начин наскоро.

person Community    schedule 21.05.2009
comment
Нещо, разделено на нула във всяко нещо, е безкрайност. - person Sam152; 21.05.2009
comment
Не, в повечето езици за програмиране това е грешка. За повечето математици то е недефинирано (което определено не е същото като да е безкрайност). - person mavnn; 21.05.2009
comment
Да, имаше време, когато мислех, че NaN е възрастна роднина... - person Dan Diplo; 29.07.2009
comment
Това е странно, не трябва ли резултатът да е NaN? - person Qwertie; 09.07.2010
comment
В повечето библиотеки, които съм виждал, 0/0 == NaN, положителен/0 == +Безкрайност и отрицателен/0 == -Безкрайност. Във всеки случай за числа с плаваща запетая -- цяло число 0/0 често се третира по различен начин. - person Joe White; 03.02.2011

Това профилиране и анализ на ефективността бяха едно и също нещо.

Тогава разбрах, че профайлърите, макар и по-добри от нищо, съдържат погрешни предположения, като например:

  • само агрегатите имат значение, не детайлите
  • необходима е статистическа прецизност при локализиране на проблеми с производителността
  • измерването на времето и локализирането на ненужни отнемащи време операции са едно и също нещо
person Community    schedule 21.05.2009
comment
Профайлърът е общо решение, което някога е имало за цел само да ви постави в полето. Не си правете труда да оптимизирате код, който профилът не доказва, че пречи на производителността. Съгласен съм, че това може да бъде подвеждащо. Имало едно време се озовах да оптимизирам метод на равенство, който беше извикан буквално трилиони пъти... докато не си казах Чакай, милиони да, трилиони не. Защо равенството се нарича трилиони пъти? Поуката на историята е, че профайлърът не е заместител на IQ. наздраве Кийт. - person corlettk; 23.05.2009
comment
@corlettk: Това, което правя сега, е да изчакам, докато програмата се забави, и след това да взема няколко проби от стека за повиквания, като използвам бутона за пауза. След това търся сайтове за обаждания, които се появяват в множество проби. Всеки такъв сайт за обаждания е място, което, ако мога да го оптимизирам, ще ускори значително програмата ми. Това противоречи на всички приети мъдрости относно профилирането. - person Mike Dunlavey; 23.05.2009

Тъй като създадох софтуера в моята „стандартна“ среда, той ще работи на машината/сървъра на всеки. Само за да открия, че съм инсталирал някои неясни библиотеки и услуги, които всъщност се използват. И след това открих, че използвах грешка, която впоследствие беше коригирана.

person Community    schedule 21.05.2009

Не можете да диагностицирате „периодични грешки“ в производството. Рестартирането на сървъра е единственият начин да го поправите.

Може би това беше ПО-вярно в ранните ми дни на ASP кодиране. Но има много добри инструменти за профилиране за намиране на течове на памет и други странни проблеми. Perfmon също предоставя много добри диагностични данни. Освен това трябва да кодирате диагностично влизане във вашето приложение.

person Community    schedule 21.05.2009

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

person Community    schedule 22.05.2009

Това разбиране на указатели и рекурсивност би било адски трудно.

Тези цели числа във VB6 имат различен размер от .Net.

Този VB6 може да прави битови операции.

Професионалните програмисти правят софтуер без грешки.

person Community    schedule 22.05.2009

Този OOP беше остарял :( Все още съжалявам, че го помислих до ден днешен.

person Community    schedule 22.05.2009
comment
Да, AOP напълно замести OOP, не разбрахте ли бележката ;-) - person corlettk; 23.05.2009

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

person Community    schedule 25.05.2009

Тази пълна поддръжка на Unicode беше предпоставка за успешно внедряване на софтуер в азиатските региони.

person Community    schedule 28.05.2009

Мислех, че писането на достатъчно добър софтуер е лесна задача

person Community    schedule 28.05.2009

Че нашите методи за развитие са избрани и използвани, защото са най-добрите от породата.

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

person Community    schedule 03.06.2009

Че хората всъщност се интересуват от използваните технологии (отворен код/затворен код).

person Community    schedule 09.06.2009
comment
Редактирайте го за лицензи, а не за технологии. - person Evan Plaice; 15.06.2010

В началото на осемдесетте, когато започнах да си играя с компютри (ZX81 с 1K памет), прекарвах часове, за да въвеждам купчини машинен код (байтове, не четим от човека асемблер) за игри от списания, като основно използвах BASIC инструкции на Poke.

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

person Community    schedule 10.06.2009
comment
ой Никога не съм имал такъв (освен писането на класове в интерактивни конзоли за забавление... само защото mac-овете имат ruby ​​инсталиран веднага). - person CodeJoust; 13.10.2009

Предположих, че ще бъде влакче в увеселителен парк с бързи коли, разпуснати жени, частни самолети и смели приключения. Просто изчакайте, докато се сдобия с този кариерен съветник...

person Community    schedule 19.06.2009

Спецификациите са пълни и достатъчни

person Community    schedule 04.07.2009

Това идентификатор на html елемент и атрибут на име, където са взаимозаменяеми.

Оказва се, че елементите с атрибути 'name' са свързани/used.referenced за POSTs и т.н., а атрибутите 'id' се използват за препратка към DOM.

person Community    schedule 17.04.2010

нишка = процес

person Community    schedule 11.08.2010

Че колона за самоличност не може да съдържа дублиращи се стойности: колона за самоличност в Sql сървър

person Community    schedule 21.05.2009

Разбира се, можете да погледнете FindBugs и PMD, но това са любимите ми грешки и трикове (всички Java):

Полетата не се отменят, те са засенчени.

Няма изричен супер.супер достъп.

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

За да получите препратка към родител на вътрешен клас, можете да използвате синтаксиса "Outer.this", за да разграничите извикванията на метод или да синхронизирате.

Класовете са „приятели на себе си“ в термините на C++, частните методи и полета на всеки екземпляр от този клас могат да бъдат препратени от всеки метод на същия клас, дори статични методи. Това щеше да направи някои от ранните ми конструктори на clone() и copy много по-прости.

Защитените методи и полета са достъпни в статичен контекст на разширяващи се класове, но само ако този клас е в същия пакет. Радвам се, че flex.messaging.io.amf не е запечатан пакет.

person Community    schedule 20.05.2009
comment
Добре, кой език е това? Почти съм сигурен, че не е C или C++. - person David Thornley; 20.05.2009
comment
Java. FindBugs и PMD са инструменти за статичен анализ на Java. - person Alan; 20.05.2009

Че продавачите управляват реалистично очакванията на клиентите. (Обучен в недостатъчно обещаващо и свръхдоставяне)

Тези софтуерни изисквания обикновено идват от проучване на пазара.

person Community    schedule 21.05.2009

Каза, че знае програмиране, трябва да е вярно!

person Community    schedule 21.05.2009

Това измерение n е екземпляр на измерение (n+1), когато са еквивалентни.

person Community    schedule 23.05.2009

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

Сега знам, че всеки го прави.

person Community    schedule 23.05.2009

Когато учех алгоритми в моето прогимназиално училище, мислех, че NPC са само неполиномиални проблеми, което означаваше, че сложността на този проблем не беше по-проста от полиномиалната. Не разбрах, че греша, докато не научих изчислителна теория в моя колеж -_-b

person Community    schedule 25.05.2009

Една програма в крайна сметка може да изглади всичките си проблеми.

person Community    schedule 29.07.2009

че:

for (int i = 0; i < myObj.variable; i = i + 1)

се оптимизира за:

int j = myObj.variable; 
for (int i = 0; i < j; i = i + 1)

уау, спрях да въвеждам извиквания на функции на мястото на j, когато разбрах, че се изпълняват ВСЕКИ път!

причина:

for (int i = 0; i < myObj.variable; i = i + 1){ 
    if (function_argument == NULL){ 
        myObj.variable++; 
    } else { 
        printf("%d", myObj.variable);
    }
}

не е същото като:

int j = myObj.variable;
for (int i = 0; i < j; i = i + 1){ 
    if (function_argument == NULL){ 
        myObj.variable++; 
    } else { 
        printf("%d", myObj.variable);
    }
}

произволен пример, но можете да видите как оптимизацията ще промени изпълнението.

person Community    schedule 14.12.2010

@Kyralessa: Струва си да се отбележи, че при повечето процесори, на асемблер/машинен език, е възможно функциите да се връщат някъде, различно от техния извикващ, докато оставят стека в добро състояние. Наистина има различни ситуации, в които това може да бъде полезно. Един вариант, който за първи път видях на 6502, въпреки че работи още по-добре на Z80, беше рутина за печат на съобщения, при която текстът, който трябва да бъде отпечатан, следва веднага инструкцията за повикване; изпълнението ще се възобнови след нулевия терминатор (или, като лека оптимизация при използване на Z80, при нулевия терминатор, тъй като оставянето на нулевия байт да бъде изпълнен като NOP би било по-евтино, отколкото да се опитвате да го избегнете).

Също така е интересно да се отбележи, че в много съвременни езици функциите имат една нормална изходна точка (която ще възобнови изпълнението след повикването), но също така могат да излязат чрез хвърляне на изключение. Дори в C човек може да използва setjmp/longjmp за симулиране на подобно поведение.

person Community    schedule 19.12.2010
comment
С кого говориш точно? Ако бяхте направили това коментар под отговора на @Kyralessa, а не отделен отговор, може би щяхме да следваме нишката малко по-добре. - person Robert Harvey; 19.12.2010
comment
@Робърт Харви: Моя грешка. Случайно натиснах отговор, а не коментар. Ще се опитам да намеря подходящото място за публикуване. - person supercat; 20.12.2010

Java е бавна. Толкова много момчета от фенове на perl на slashdot връщат (sp???) това, тъжно е.

person Community    schedule 25.05.2009

Че щях да програмирам във VB завинаги, сега съм c#.

person Community    schedule 10.06.2009
comment
Вярвахте ли, че ще имате нужда само от 640K RAM завинаги? - person Luc M; 10.06.2009