2010-01-02, 03:15
#13
2010-01-02, 11:14
#14
Citat:
Ursprungligen postat av gosh
och vad är viktigast när man skriver bra kod och tänka på?
Att det inte finns ett universalt svar på frågan. Bra kod för ett tillfälle är kanske inte lika bra kod för ett annat.
För Google Code Jam så måste man skriva korrekta lösningar till problemen under så kort tid som möjligt, vilket generellt sett gör minimalistisk (i både termer av antalet tecken och "kod-komplexitet"), men ändå välgenomtänkt, kod till vinnare. Dokumentering (både i form av kommentarer och långa beskrivande variabel/funktions-namn) är då oftast bara slöseri med tid. En programmerare som där kan hålla många bollar uppe i luften och som har kapaciteten att komma ihåg vad variabeln "MP" gör har då ett litet övertag över en programmerare som inte gör det.
Det viktigaste när man skriver bra kod är att lyssna på vad andra tycker om den. Om majoriteten tycker att koden är dålig så är den nog också dålig.
2010-01-02, 13:44
#15
__________________
Senast redigerad av snigelfalafel 2010-01-02 kl. 13:46.
Senast redigerad av snigelfalafel 2010-01-02 kl. 13:46.
2010-01-02, 14:22
#16
Citat:
Ursprungligen postat av snigelfalafel
det är väl ändå datorn som exekverar koden, inte människor? kod != källkod.
Du får nog ursäkta mig. För mig så är "kod" bara ett kortare sätt att skriva "källkod" på, i ett sammanhang som detta.
Som du själv nämnde: "en bra kodare skriver bra kod"
Googlar man på "good code" så diskuteras det om kvaliteten på källkoden och inte direkt om applikationens kvalitet (även om båda oftast är starkt relaterade till varandra).
För att citera denna sida: http://www.ccs.neu.edu/home/will/com1390/goodcode.html
Citat:
There is a big difference between
- working code
- correct code
- good code
Good code is abstract, straightforward, and efficient enough to do the job. Good code is easy to understand and to maintain. Good code evolves as requirements change. It doesn't have to be thrown away when a new feature is added.
Not all correct code is good code. It might be unnecessarily inefficient or overly complicated or insufficiently abstract. Poor code is hard to maintain. When requirements change, it is often easier to replace poor code with newly written code than to try to understand and to modify the poor code.
Not all code that works is correct. It might happen to work when it is linked together with one particular implementation of an abstract data type that it uses, but not when it is linked together with an alternative but equally correct implementation of that data type. It might happen to work when presented with ordinary data, but not with unusual data.
Not all correct code works, but it is far more likely to work than incorrect code. Compiler bugs sometimes prevent correct code from working as it should. More often, some other module may contain a bug that prevents a correct module from working. With good code, we can isolate these bugs. With poor code, it is harder to determine which module is at fault.
Not all good code is correct, but good code is much more likely to be correct than poor code. It's hard to convince anyone that poor code is correct even when it is. What's more, any attempt to add new features to poor code is likely to introduce bugs that are hard to find and to fix. With good code, you can find and fix any bugs. In the long run, good but incorrect code is more valuable than poor but correct code.
- working code
- correct code
- good code
Good code is abstract, straightforward, and efficient enough to do the job. Good code is easy to understand and to maintain. Good code evolves as requirements change. It doesn't have to be thrown away when a new feature is added.
Not all correct code is good code. It might be unnecessarily inefficient or overly complicated or insufficiently abstract. Poor code is hard to maintain. When requirements change, it is often easier to replace poor code with newly written code than to try to understand and to modify the poor code.
Not all code that works is correct. It might happen to work when it is linked together with one particular implementation of an abstract data type that it uses, but not when it is linked together with an alternative but equally correct implementation of that data type. It might happen to work when presented with ordinary data, but not with unusual data.
Not all correct code works, but it is far more likely to work than incorrect code. Compiler bugs sometimes prevent correct code from working as it should. More often, some other module may contain a bug that prevents a correct module from working. With good code, we can isolate these bugs. With poor code, it is harder to determine which module is at fault.
Not all good code is correct, but good code is much more likely to be correct than poor code. It's hard to convince anyone that poor code is correct even when it is. What's more, any attempt to add new features to poor code is likely to introduce bugs that are hard to find and to fix. With good code, you can find and fix any bugs. In the long run, good but incorrect code is more valuable than poor but correct code.
2010-01-02, 15:01
#18
Citat:
Ursprungligen postat av Weeblie
Du får nog ursäkta mig. För mig så är "kod" bara ett kortare sätt att skriva "källkod" på, i ett sammanhang som detta.
och för mig är kod = opcode, källkod = källkod i vilket sammanhang som helst
det är bara programmerare som berörs av bra källkod därav borde bra kod vara kod som flyter felfritt i ren binär form, per definition. det är väl därför vi programmerar ifrån första början? äh, vi har båda två fått fram våra poänger och kan nog nöja oss med att vi helt enkelt bara har olika definiton av kod.
2010-01-03, 17:42
#21
2010-01-03, 17:56
#22
2010-01-03, 20:46
#23
Skapa ett konto eller logga in för att kommentera
Du måste vara medlem för att kunna kommentera
