Redovito sam takav kod vracao s Code Reviewa na prepravak, ne samo da je iznimno rijedak slucaj da ga netko koristi nego je kao i sto je @dmitrecic vec rekao i iznimno necitak i nelogican.
Svaka cast svakome, ali kod mene takav kod nema prolaz.
Sad reci da ne podnosiš ni one koji igraju FPS sa invert mouse setting? 
Uz dobru statičku analizi koda, takav neočekivani dio koda neće u produkciju…
Uz pogrešno (ili bolje rečeno nepotpuno) napisan test koji nije uzeo u obzir sve ekstreme, 'oće.
Čini mi se da onda except-pattern pravi veći kompleks.
Disclaimer: nisam koristio.
Edit: pogrešno čitam, except-parens piše. Ali ima neki exceptRange.
Nisam mislio na testove, nego na statičku analizu koda…kao što je linkao belmin.
Doduše, ja pišem vlastite skripte za statičku analizu koda, pa se igram Boga. 
Jer kada već radim svoju analizu, reko što nebi malo i kompajlirao javascript prije nego ga dam u ruke drugim kompajlerima.
Pa sam tako recimo sam sebi omogućio JS sintaksu:
var ime = "Miki";
var pozdrav = "Hello $ime!";
…puno prije nego je to stiglo sa nekakvim modernim ECMA-om ili nečijim tuđim kompajlerima… A Bogme mi je moja sintaksa ljepša od
var pozdrav = "Hello ${ime}!"; // <-ovaj vrag skoro kao da niti nije pojednostavio izvornu: "Hello "+ime+"!";
Uglavnom, najveće oslobođenje u programiranju sam osjetio kada sam code počeo puštati kroz svoje (pred)kompajlere…zato jer:
-dok ovisiš samo o tuđim kompajlerima, onda si ograničen sintaksom programskog jezika i eventualno mogućnostima dodatnih kompajlera koje koristiš.
-a kada počmeš sam utjecati na kompajliranje svog codea, onda granice više ne postoje. IMHO.
Naravno, to nosi za sobom i svoju neku problematiku…svjestan sam toga…
Zabava moze da pocne 
3 Likeova
Kakvi su to compileri?
Jelda, ja isto mislim. Pustim tako jedan post i imam se što guštati nekoliko dana
A jbga…valja čuti sve kritike
The “bus factor” is the minimum number of team members that have to suddenly disappear from a project before the project stalls due to lack of knowledgeable or competent personnel.
1 Like
Imam i za css fileove…i za JS.
Za css sam si recimo uveo sintaksu:
@mobile{
... //ovdje idu pravila koja se tiču isključivo djelova stranice koji se prikazuju na mobitelima
}
@desktop{
...//...isključivo za desktop
}
I sad kompajler takav file razbija u dva css file-a, a framework je podešen tako da desktop clienta posluži samo sa onim css fileovima koji sadrže pravila isključivo za desktop…a mobile clienta samo sa pravilima za mobile.
U suštini je to stvar optimizacije jer nećeš svakom prosljeđivati sva pravila… desktop će dobiti samo ono što se njega tiče i mobiteli će dobiti samo ono što se njih tiče.
…ali pored optimizacije, ovako nešto ti daje potpunu kontrolu i da isporučuješ stranicu “as desktop version” ili “as mobile version”…po želji. Što je također praktično ponekad.
Ovo gore naravno ne isključuje i mogućnost korištenje @media screen pravila.
Osim toga taj moj css kompajler je omogućio i svašta nešto što srećeš u sass/less sintaksi. …ali to su oni ipak radili bolje, tako da bi radio kombinaciju. Prvo bi propustio kroz moj kompajler…pa onda tek kroz njihov.
Što se tiče JS-a, nisam puno utjecao na sintaksu…osim već spomenute sintakse za praktičnije zbrajanje varijabli sa stringom.
Ali to mi nije bilo primarno…to sam ubacio tek onako pošto sam već kompajlirao code, pa sam eto tako iz šale si omogućio i to proširenje sintakse. Bilo je svakako cool spoznati da se moguće uzdići iznad pravila ugrađene sintakse…i na toj razini također djelovati.
A zašto sam primarno kompajlirao code?
Zbog multilanguage …htio sam multilanguage integrirati da bude maksimalno jednostavan za onoga koji kodira…i da stvar bude optimizirana. Neke želje su bile:
- Da se ne učitava cijeli translation-data na client stranu, samo zato jer će negdje u javascriptu biti poneki komad teksta koji se prevodi.
- S druge strane nisam htio da itko mora gubiti sekundu svoga vremena da povezuje išta oko varijabli za prijevod.
- Da prijevodi nisu pred developerom u obliku varijabli…nego da doslovice kucaju stringove kako im padaju riječi na pamet…a da pozadinksi sustavi to sve hendlaju…
Vuglavnom, došao sam do toga da developer treba pisati ovako nešto:
var x = "{{ivo ide u školu.}}";
var days = {{['pon','uto','sri','čet','pet','sub','ned']}}; //ovo je zapravo array...i ova sintaksa bi skršila JS parser ukoliko moj predkompajler to nebi obradio.
…sve ostalo odrađuje kompajler.
Znači, developer samo treba u duple vitičaste staviti ono što želi da se prevodi…i dalje nit brige niti pameti za njega.
Također, developer je na ovaj način mogao prevoditi i komentare u codeu ako bi slučajno i tako nešto poželio, npr:
var x = 5+5; // {{Ovo je komentar koji će biti preveden nakon što kompajler obavi svoje}}
Btw…kompajler automatski surađuje sa admin panelom kojeg puni sa novim tekstovima za prijevod koji se pojave…tako da admini dobivaju notifikacije kada se pojave novi tekstovi i sve je smooth and easy…
Također admin panel može povuči i automatske prijevode od Googlea API-a prije nego li oko admina baci konačni review prijevoda.
Uglavnom, bilo je toga jako puno vezano uz to multilanguage rješenje…mnogi su me hejtali kada sam to radio (ništa čudno :)) …a na kraju je ispalo da su neki poznati frameworci išli istim pristupom, hehe.
Ako će te zanimati, bila je tema gdje sam detaljnije opisao što sam i kako radio: Multilanguage web site
Evo i admin panela, kratki slatki video gdje se vidi kako stvar šljaka: https://www.youtube.com/watch?v=ppTFQf88PEo&t=2s
Ono što sam zahebao, sustav sam integrirao unutar jednog projekta…a nisam napravio admin panel kao vanjsku zasebnu jedinicu…s kojom bi mogao upravljati bilo kojim projektom. (Koji naravno plati da koristi moj alat za multilanguage :))
Ali to ću popraviti/nadograditi kada za to bude vrijeme.
Jer ovo rješenje koje sam osmislio, je zlato. 
P.S. taj compajler za ugradnju multilanguage-a jednako obrađuje i .js i .php fileove. Ako treba, mogu se prevoditi i djelovi .css file-a, hehe. Ma može bilo što obraditi …pa i obične .txt fileove ako ima potrebe. Nema baš nikakvog ograničenja.
To je krivi pristup.
Npr. dane drzis u bazi prijevode ili file-u, a u onda u js ili php ili kako vec stavljas kljuceve i automatski se prevode na jezik koji je odabran. Ako nije ni jedan ide defaultni jezik. Tako rade frameworci.
Translacije se drze u cache-u,
Bilo je o tome rijeci. Developer nema sto rucno pisati text na bilo kojem jeziku nego da iskljucivo koristi kljuceve.
Ovo je bitno, jer sutra ce ti trebati native mobilna app(java , kotlin, swift, xamarin, react native, cordova itd) koja ce trebati prijevode, onda ces kad tad morati koristiti reactjs ili vuejs itd…
S ovakvim pristupom onda nastane cuspajz i tesko odrzavanje.
Ne vidim nikakvu prednost takvih translacija u odnosu na ono kako se sad radi.
Meni je osobno ES6 template-literal string sintaksa sasvim citljiva.Pored toga donosi i jos neke stvari, npr:
const text = `
Hello there
New row here
No string concat
`
Zatim mozes raditi i ovakve stvari, ako si koristio React vrlo vjerovatno ce ti biti slicno
const options = ['First', 'Second', 'Third']
const template = `
Current options are:
${options.map((option, index) => `
#${index} - ${option}
`)}
`
document.body.innerHTML = template
I sve to nativno
Tko ce iza tebe odrzavati taj code? Moras razmisljati unaprijed. Ako kazes nije me briga, onda lose razmisljas.
Sve to stoji, ali moj naglasak je bio na tome da sam to imao prije nego je bilo native. …i u mogućnosti toga da nadilazimo granice (kojih nema)
A što se tiče čitljvosti, native sintaksa je sasvim ok i nudi više toga da se napiše u vitičastima… …svejedno za samo ubacivanje varijable u string, mislim da je praktičnije tipkati:
"ovo je string sa $varijablom"
Uglavnom, ja nisam u confliktu sa native sintaksom, mogu koristiti oboje
Opet ću ti reći, da su svi tako razmišljali i danas bi tipkao u asembleru. Izlazak iz granica i normativa pridonosi evoluciji i razvoju.
Nimalo mi nije neugodno što sam pravio stvari za sebe prije nego su postale native… štoviše, jako sam ponosan na to.
No mali spektar onoga što sam napravio je postalo native ili je došlo kroz razne frameworke…još puno toga treba tek da dođe.
Tko će iza mene tipkati taj code? Pa što god da tipkaš moraš proučiti dokumentaciju okoline u kojoj radiš…po ničemu tu nisam drugačiji.
…niti ja puno odskačem od prosjeka, samo ga malo popravljam
Nije točno.
Taj code koji postoji je prihvaćen među zajednicom.
Treba proći 10 - 15 godina od pojave da se vidi da li je neka tehnologija prihvaćena ili ne.
Ima puno programskih jezika, ali većina ih polako , ali sigurno umire, kao i razno razni frameworci.
Tako je i sa bazama, alatima i sl.
Ako je nešto hipi trenutno, to ne znaci da neće nestati.
Pa da, treba XX godina da se profiltrira najbolje od svih onih koji su izlazili iz granica.
Da nitko nije izlazio iz granica … i nakon 10, 15 ili 150 godina uživao bi i dalje u asembleru.
Ne kužim što onda nije točno, a potvrdio si me
I u tom procesu evolucije, najnormalnije je da te danas ima sutra nema…tj. da tehnologije dolaze i prolaze…
1.Moraš objaviti svoj code, teoriju, principe, dokumentaciju – sve u detalje - -npr. normjs
2.Ako preživi 10-15 godina – prihvaćeno je, ako ne preživi nije
Vrlo jednostavno.
Ono što je problem, što nitko nije još vidio ništa od tebe, recimo normjs koji se najviše spominjao, pa regex za datume itd…
Stavio sam linkove kako treba izgledati opis , business flow itd…
Nema ničega, ako nema ničega, nema ni teorije, jel kužiš poantu?
Dakle, ako nešto napraviš i ugradiš u svoju app, a nitko to nije vidio, mislit će da je čušpajz.
Da su svi radili za sebe i da ništa nisu objavili, kucali bi i dalje 1 i 0.
O tome se radi.
2 Likeova
Naidjo’ na slideshow:
1 Like