как да се избегне спагети код


Отговор 1:

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

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

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

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


Отговор 2:

Кодът за спагети изглежда така:

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

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

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

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

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


Отговор 3:

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

(1) Ще намерите (goto) използване в много проекти, Проверете ядрото на Linux и изпълнението на езика Ruby в C.

(2) Използвайте ясни имена за класове, методи, променливи и функции

(3) Предпочитайте дълги имена на функции, които демонстрират предназначението на функцията пред кратки имена и коментари.

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

(5) Когато мислите за абстракция, помислете за местата, които ще промените, когато добавяте / премахвате / модифицирате функция. Намалете броя на тези места, доколкото е възможно.

(6) Използвайте коментари, когато трябва да ги напишете, за да разберете общата картина. Кодът трябва да е достатъчно ясен, без да въвеждате коментари за малки подробности.

(7) Документирайте всеки файл и всяка функция.

(8) Не оптимизирайте нищо, докато не осъзнаете, че наистина се нуждаете от това, или не знаете от самото начало, че това е необходимо.

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


Отговор 4:

Всички останали отговори, плюс ... Ще намерите много онлайн уроци, дори професионалните платени имат склонност към кодове за спагети. Един от най-разпространените миризми на iOS код в много уроци е монолитният контролер за изглед. Писателите на уроци и начинаещите програмисти са склонни да поставят целия код в един клас, вместо да разпространяват функционалността на техния код. Трудно е да се избегне, когато уроците са написани лошо! Другият проблем е, че вие. просто не може да се превърне в добър кодер само като чете книги за добро кодиране или дизайнерски модели, тъй като проблемите, които те решават, нямат никакво значение за вас, освен ако не сте написали лош код _ И_ е трябвало да модифицирате или поддържате свой собствен или чужд код и да ви намерите отделете повече време за модифициране на това, което според вас трябва да отнеме пет минути и два реда, в крайна сметка отнема часове за отстраняване на грешки.

Goto като цяло са „лоши“, но те могат да се използват за решаване на проблеми и не са лоши, ако се използват със знания и съсредоточени намерения. Начинаещите нямат опит, за да имат знанията. Указателите обикновено се оказват лоши неща и за начинаещи. Но опитните програмисти знаят кога и. как да ги използвам.

  1. Напишете код. 2. Научете малко дизайн. 3. Напишете код. 4 Научете повече дизайн. 5. След известно време вие. ще започне да вижда проблеми във вашия собствен код и активно ще търси решения сам.

Отговор 5:

Как да избегнем писането на код за спагети?

На теория, като знам какво е и не го пиша на първо място,

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

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

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


Отговор 6:

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


Отговор 7:

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

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


Отговор 8:

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