Testa punktu skaitīšanas sistēma (Gabaldarbs)

[jurchiks]

Es kā reizi centos uzrakstīt normāli (nesanāca, jo js ir tizla valoda, scalā būtu uzrakstījis 7 minūtes un 2x mazāk rindām.) un atbilstoši situācijai, nenormāli ir uzrakstīt 20 liekas rindiņas un 2x vairāk simbolu, lai rastos ilūzija par to, ka tā ir labāk.

Ja tev līniju skaits ir svarīgāks par koda lasāmību, tad tev kaut kas nav kārtībā.

[daGrevis]

http://davedellacosta.com/cljs-dom-survey

[daGrevis]

2013., varam rakstīt Lispu broverī.

[codez]

Raksti CoffeeScript, raksti LiveScript, raksti TypeScript, raksi Dart, raksti ClojureScript, vai Scala.js. Pat tu no Python un PHP vari dabūt ārā JavaScript un palaist to uz broversa.

Jākonfigurē build sistēma, nav saderība ar bibliotēkām, nav atbalsta IDĒs, sarežģītāk debugot kodu, nevarēšu nodemonstrēt kodu jsfiddlē, utt. utjp.

Kopumā neatmaksājas, jo tik jau ļoti js nav sliktāka par citiem variantiem.

[codez]

Ja tev līniju skaits ir svarīgāks par koda lasāmību, tad tev kaut kas nav kārtībā.

Kārtībā kā reizi nav tev, jo tu domā, ka ieliekot viena burta vietā vārdu, kurš tavā piemērā lielākajā daļā vietu neatbilst tam, ko konkrētā vietā tas apzīmē, pēkšņi viss ir labi.

Tavs kods nav lasāmāks. Manā kodā vismaz 1 burtu mainīgie nemaldina un ļauj pašam izdomāt, kas ar tiem domāts. Tavā kodā nepareizi izvēlēti vārdi ne tikai apgrūtina lasīšanu, bet arī maldina.

Un vēl tev ir problēma ar pielekšanu - tas ir uz ātrumu rakstīts kods, kur vienīgā nozīme ir laikam, kurā tika iegūts funkcionējošs kods.

[jurchiks]

Man kaut kā Clojure vairāk liekas ezotēriska valoda...

 

...nav atbalsta IDĒs, sarežģītāk debugot kodu...

Nezinu, par kurām IDE tu runā, bet PHPStorm atbalsta ļoti daudzas valodas.

nevarēšu nodemonstrēt kodu jsfiddlē

jsfiddle kreisajā malā zem Languages var nomainīt uz CoffeeScript.

vārdu, kurš tavā piemērā lielākajā daļā vietu neatbilst tam, ko konkrētā vietā tas apzīmē

Piemēram?

Tavs kods nav lasāmāks. Manā kodā vismaz 1 burtu mainīgie nemaldina un ļauj pašam izdomāt, kas ar tiem domāts.

Tieši tā, lasītājam speciāli jādomā, ko kas nozīmē, jo tas nav skaidrs uzreiz. Rezultātā koda lasīšana aizņem daudz vairāk laika, kas nav labi.

[codez]

jsfiddle kreisajā malā zem Languages var nomainīt uz CoffeeScript.

Domā es nezinu, bet tev jau prāta nepietiek, lai izdomātu, ka scala tur nav atbalstīts.

 

Piemēram?

var questions = [
    { question: "Esi komunikabls?", answerGroups: [[1, 2], [2, 3], [], [3, 4], [4, 5]] },
    { question: "Esi jautrs?", answerGroups: [[2, 3], [1, 4], [3, 4, 5], [2, 4], [1, 5]] }
];

1) question - ja viss masīvs ir questions, tad question ir tā elements. tātad objekts, kurš apzīmē visu jautājuma modeli. Tātad question vietā ir jāraksta text, jo konkrētais question satur tikai jautājuma tekstu, nevis visu jautājuma modeli.

2) answersGroups neapzīmē grupas modeļus, bet gan grupas id, tāpēc tā vietā ir jāraksta, piemēram, answersGroupsIds. Pie tam answers, jo satur datus par visām atbildēm.

var index = 0; 

3)Globāls mainīgais index - principā konkrēti nepasaka par mainīgā saturu neko.

var answer = $(this).attr('aid');

4)Tas nav atbildes modelis, bet gan tikai atbildes id, tātad answerId.

var answerGroups = questions[index].answerGroups[answer];

5)answerGroups nesatur masīvu ar grupas modeļiem, bet gan tikai masīvu ar grupas id masīviem, tāpēc answersGroupsIds.

for (var ag in answerGroups)

6)ag - hm saīsinājums (i like that), pieņemsim, ka tu tur domāji answerGroup, bet diemžēl tas nav atbildes grupas modelis, bet gan tikai masīva indeks. Labāk lietot vienkārši i vai answersGroupsGroupIndex, vai groupIndex.

for (var g in groups)

7) g - hm, atkal saīsinājums (i like that too), pieņemsim, ka tu domāji group, bet diemžēl, tas nav grupas modelis / grupa, bet gan tikai grupas indeks, piemēram, groupIndex.

 

 

 

Tieši tā, lasītājam speciāli jādomā, ko kas nozīmē, jo tas nav skaidrs uzreiz. Rezultātā koda lasīšana aizņem daudz vairāk laika, kas nav labi.

Atklāšu tev jaunumu - lasot kodu vispār ir jādomā līdzi.

Ja manā gadījumā lasītājs pats sapratīs pareizi, kas tur ir domāts, tad tavā gadījumā viņš paņems tavu nepareizo nosaukumu un sāks kodēt un tikai sākoties kļūdām, sapratīs, ka nosaukums ir nepareizs, tad sāks analizēt, kas galu galā slēpjas zem tā nepareizā nosaukuma.

 

 

P.S. Reāli dabā labi, ja 10% pilno nosaukumu pilnīgi un viennozīmīgi pasaka, kas tajā mainīgajā glabājas - un šeit nerunāju tikai par kaut kādu privātu kodu, bet ari par lieliem opensource projektiem un plaši lietotām bibliotēkām. Un bieži pat nav iespējams sakarīgos apmēros nosaukt mainīgo bez divdomībām.

Visos citos gadījumos mainīgā nozīme ir jāspēj uztvērt no koda konteksta, ja to, lasot kodu nevar izdarīt, tad būs grūti.

Edited December 12, 2013 by codez

[Kavacky]

“There are only two hard problems in computer science: cache invalidation and naming things.“ /Phil Karlton/

"There are only two hard problems in computer science: cache invalidation, off-by-one errors and naming things."

[edw]

Domā es nezinu, bet tev jau prāta nepietiek, lai izdomātu, ka scala tur nav atbalstīts.

 

var questions = [
    { question: "Esi komunikabls?", answerGroups: [[1, 2], [2, 3], [], [3, 4], [4, 5]] },
    { question: "Esi jautrs?", answerGroups: [[2, 3], [1, 4], [3, 4, 5], [2, 4], [1, 5]] }
];

1) question - ja viss masīvs ir questions, tad question ir tā elements. tātad objekts, kurš apzīmē visu jautājuma modeli. Tātad question vietā ir jāraksta text, jo konkrētais question satur tikai jautājuma tekstu, nevis visu jautājuma modeli.

2) answersGroups neapzīmē grupas modeļus, bet gan grupas id, tāpēc tā vietā ir jāraksta, piemēram, answersGroupsIds. Pie tam answers, jo satur datus par visām atbildēm.

var index = 0; 

3)Globāls mainīgais index - principā konkrēti nepasaka par mainīgā saturu neko.

var answer = $(this).attr('aid');

4)Tas nav atbildes modelis, bet gan tikai atbildes id, tātad answerId.

var answerGroups = questions[index].answerGroups[answer];

5)answerGroups nesatur masīvu ar grupas modeļiem, bet gan tikai masīvu ar grupas id masīviem, tāpēc answersGroupsIds.

for (var ag in answerGroups)

6)ag - hm saīsinājums (i like that), pieņemsim, ka tu tur domāji answerGroup, bet diemžēl tas nav atbildes grupas modelis, bet gan tikai masīva indeks. Labāk lietot vienkārši i vai answersGroupsGroupIndex, vai groupIndex.

for (var g in groups)

7) g - hm, atkal saīsinājums (i like that too), pieņemsim, ka tu domāji group, bet diemžēl, tas nav grupas modelis / grupa, bet gan tikai grupas indeks, piemēram, groupIndex.

 

 

 

Atklāšu tev jaunumu - lasot kodu vispār ir jādomā līdzi.

Ja manā gadījumā lasītājs pats sapratīs pareizi, kas tur ir domāts, tad tavā gadījumā viņš paņems tavu nepareizo nosaukumu un sāks kodēt un tikai sākoties kļūdām, sapratīs, ka nosaukums ir nepareizs, tad sāks analizēt, kas galu galā slēpjas zem tā nepareizā nosaukuma.

 

 

P.S. Reāli dabā labi, ja 10% pilno nosaukumu pilnīgi un viennozīmīgi pasaka, kas tajā mainīgajā glabājas - un šeit nerunāju tikai par kaut kādu privātu kodu, bet ari par lieliem opensource projektiem un plaši lietotām bibliotēkām. Un bieži pat nav iespējams sakarīgos apmēros nosaukt mainīgo bez divdomībām.

Visos citos gadījumos mainīgā nozīme ir jāspēj uztvērt no koda konteksta, ja to, lasot kodu nevar izdarīt, tad būs grūti.

 

 

Tu te tagad piesienies pie viņa mainīgo nosaukumiem, paanalizē tieši tādā pašā veidā savus! Vismaz uz viņa koda paskatoties, uzreiz var saprast, kas ir kas, ko nevar teikt par Tavu piemēru, tur vajag 2x vairāk laika, lai saparstu, kas un kā notiek.

[marrtins]

Piesienas jau jurčiks :)

[codez]

Tu te tagad piesienies pie viņa mainīgo nosaukumiem, paanalizē tieši tādā pašā veidā savus! Vismaz uz viņa koda paskatoties, uzreiz var saprast, kas ir kas, ko nevar teikt par Tavu piemēru, tur vajag 2x vairāk laika, lai saparstu, kas un kā notiek.

 

Mana nākoša frāze būs tik vienkārša, ka tu pat to spēsi saprast. Primārais mērķis bija maksimāli ātri uzrakstīt kodu, nevis uzrakstīt kodu, kuru lasīs wanabe programmētāji ar smadzeņu darbības traucējumiem.

Edited December 12, 2013 by codez

[codez]

Tavu piemēru, tur vajag 2x vairāk laika, lai saparstu, kas un kā notiek.

 

Bet, ja nopietni. Cik daudz laika tev prasīja saprast manu un cik daudz jurchika kodu?

Ar ko tu mēriji laiku?

Kā tu novērtēji, ka jābeidz mērīt laiku - respektīvi, kods saprasts?

Kuru kodu tu centies saprast pirmo?

[daGrevis]

> "There are only two hard problems in computer science: cache invalidation, off-by-one errors and naming things."

 

Ha!

 

Taisnība jau jums ir abiem. Codeza x-y-z nav lasāms, bet jurčika almostCorrectVarName var būt maldinošs.

[rATRIJS]

Nu šajā gadījumā jau vairāk taisnības ir codez, manuprāt. Viņa dotais piemērs bija tieši tas - piemērs. Tas nav koda gabals, kuru vajadzētu uzreiz likt uz master branch-a un rādīt visiem saviem komandas biedriem kā piemēru. Tas pats attiecas arī uz sacensībām, kur ar kodu ir jāstrādā īslaicīgi un nav jāstrādā ar citiem cilvēkiem ( vai arī ja ir, tad darbs būs gana sadalīts / pārdomāts, lai nevajadzētu lasīt vienam otra kodu ). Un izmantot vien-burtu nosaukumus un one-liner-us šādās situācijās IMO ir ātrāk.

 

Tiesa komandas vidē, kur tiek rakstīts kods, kas ir arī jāuztur būtu jāizmanto normāli nosaukumi.

[jurchiks]

Domā es nezinu, bet tev jau prāta nepietiek, lai izdomātu, ka scala tur nav atbalstīts.

Tālu dzīvē tiksi. Runa neiet par to, ka tur nav atbalstītas VISAS daGrevis nosauktās valodas, bet vismaz viena, arguably, labāka alternatīva ir.

 

2) answersGroups neapzīmē grupas modeļus, bet gan grupas id, tāpēc tā vietā ir jāraksta, piemēram, answersGroupsIds. Pie tam answers, jo satur datus par visām atbildēm.

Smagi tev ar angļu valodu, skatos... Tāds nosaukums ir gramatiski nepareizs.

 

Piemērs: "answer sheet". Lapa satur daudzas atbildes, nevis vienu, bet tā, kā vārds ir ģenitīvā, tad nav tur nekāda 's'.

 

Anyway: http://jsfiddle.net/jurchiks/Y8EDf/

Edited December 13, 2013 by jurchiks