Adott a következő függvény:
function blacklisted(hostname)
{
var spl, ret, hn;
spl = hostname.split(".");
if (spl.length >= 2)
{
hn = spl[spl.length - 2] + "." + spl[spl.length - 1];
ret =
(hn == "x.com") ||
(hn == "y.com") ||
(hn == "z.com")
;
return ret;
}
else
{
return false;
}
}
Ez így tökéletesen működik. Ha viszont kiveszem a ret
változót:
function blacklisted(hostname)
{
var spl, hn;
spl = hostname.split(".");
if (spl.length >= 2)
{
hn = spl[spl.length - 2] + "." + spl[spl.length - 1];
return
(hn == "x.com") ||
(hn == "y.com") ||
(hn == "z.com")
;
}
else
{
return false;
}
}
Akkor undefined
-et ad vissza! Úgy, hogy ha belül kialert
elem azt amit vissza kell adnia, akkor az stimmel! Tehát belül még jó, de mire visszatér, nem jó! Több, mint egy órám ráment erre, mire rájöttem, de csak arra jöttem rá, hogy így működik, arra nem, hogy miért, hiszen működnie kellene külön visszatérési változó nélkül is...
Rated: WTF?!
Természetesen a gugliban csak olyan esetet lehet találni, hogy lehagyta a delikvens a return
-t a függvényből; hát úgy persze, hogy undefined
, de itt nem volt lehagyva...
- TCH blogja
- A hozzászóláshoz be kell jelentkezni
Hozzászólások
Nope, ha zárójelbe tettem se működött, de nem is csoda: én kitettem a pontosvesszőt, szóval nem az volt a baja, hogy betolta előtte és ezért return;
-ra degradálódott a kód.
- A hozzászóláshoz be kell jelentkezni
Nem jó helyre tetted a zárójelet, ahogy én most a választ. :)
- A hozzászóláshoz be kell jelentkezni
Röhögni fogsz: miután elhúztam aludni, az álmatlan fetrengés közepette beugrott, hogy oké, zárójel az volt, de lehet, hogy az a baja, hogy nem ugyanabban a sorban nyitottam meg, mint ahol a return
van? És tényleg... :)))
Köszi a linket; erre nem hiszem, hogy rájöttem volna, mert ez kb. a logika teljes hiánya, hogy egy nyelv önhatalmúlag szúrkodjon be utasításlezárásokat oda, ahova épp akar és hogy a helyes végrehajtás egy semleges területen lévő - elméletileg szabadon mozgatható - zárójel függőleges pozíciójától függjön. (De már az is fail, hogy egyáltalán zárójelbe kell rakni.) Plusz egy érv, amikor majd kérdezik tőlem, hogy miért utálom a JS-t...
- A hozzászóláshoz be kell jelentkezni
Sok furcsaság van a JS-ben, de ez a viselkedés azért még a könnyebben indokolhatóak között van. Megjegyzem azért, hogy a kedvenc nyelvem a Python, ahol ugye szignifikáns az indentálás és nincs sorvégi pontosvessző. Szóval szerintem a problémádat is az okozta, hogy a JS-ben opcionális a sorvégi pontosvessző és a JS közösség mai napig nem tudott megállapodni abban, hogy ki illik-e rakni, vagy sem. Te még a hagyományos stílust követed; becsülettel kiraktad mindenhova a pontosvesszőt. Régen én is kiraktam mindenhova, aztán idővel lustaságból elhagytam (illetve megszoktam, hogy Pythonban se rakok). Pontosvessző nélküli stílusnál egyből feltűnt volna, hogy hopp, itt egy speciális 'return' kifejezés, ami gyakorlatban 'return;'-t jelent az értelmező számára, mivel egy önmagában is megálló szintaktikai elem. A 'ret =' sornál ott az egyenlőségjel, amivel jelzed, hogy nincs lezárva még a sor.
Pythonban egyébként gyakran használom hasonló célra a zárójeleket, hogy több soros kifejezéseket írjak [pl. több soros hosszú from ... import (valami1, valami2)], mert jobb szeretem, mint a \ jeles szintaktikát.
- A hozzászóláshoz be kell jelentkezni
Jó, csak a Pythonnak saját szintaxisa van, a JS meg a C/C++-tól örökölte a sajátját, a vezérlőszerkezetektől elkezdve az alap szemantikáig mindent, többek között a multi-line utasításokat és az egyes utasításokat lezáró pontosvesszőt is (azaz: milyen "sorvégekről" is beszélünk, ha az utasítások többsorosak lehetnek és külön jelezni kell a végüket?) és arra pakolta rá a maga vackait, tehát egy ilyen szerkezet esetén az embernek eszébe se jut, hogy a nyelv majd magától odaképzel (jajj...) egy vezérlő írásjelet. És ha odaképzeli, akkor tulajdonképpen le is szögezhetjük, hogy tkp. kötelező az, hisz a nyelv maga rakja oda, ha nincs ott, csak még ezt is bénán - értsd: inkonzisztensen - csinálja.
Miért? Mert a return
után az interpreter ugyanúgy kifejezést vár, ahogy a zárójel és az egyenlőségjel után is, ennek megfelelően az egyetlen hely, ahová józan paraszti ésszel "beinjektálhatna" egy pontosvesszőt, az a legközelebbi nyitópár nélküli blokkterminátor pozíciója. És ha zárójelbe teszem, vagy ha az egészet értékadással csinálom, akkor kb. ez is történik, csak nélkülük nem. (De egyébként oda se szúrogasson be: dobjon hibát, az korrekt és logikus.) Egyszer így, egyszer úgy. Holott logikailag a három között zéró különbség van. És ezen még csak súlyosbít az, hogy az sem mindegy, hogy hol - melyik sorban - nyitom a zárójelet egy többsoros utasításban, hiszen a vezérlő és a kifejezés belseje között a nyitó zárójel pozíciójának logikailag teljesen irrelevánsnak kéne lennie, de a JS szerint nem az.
Magyarán az interpreter idevágó logikájában van egy masszív logikai inkonzisztencia. És mindez azért, mert ez az inkonzisztencia magában a koncepcióban van: egyszerre van lehetőség a multi-line utasításra és igény a sorvégi pontosvesszőre, ami aztán összeakad, a programozó meg felváltva - rosszabb esetben egyszerre - őszül és kopaszodik...
- A hozzászóláshoz be kell jelentkezni
Nem akartam ennyire trollba átmenni, tényleg az hittem lehet értelmesen átbeszélni a témát. De ám legyen:
a JS meg a C/C++-tól örökölte a sajátját
Nem, a JS max közvetetten örökölte a C egyes nyelvi szabályait. Közvetlenül a JAVA-tól örökölt szintén nem mindent. Idézek a Wikipediából: "Netscape Communications then decided that the scripting language they wanted to create would complement Java and should have a similar syntax". Kiemelés tőlem.
tehát egy ilyen szerkezet esetén az embernek eszébe se jut, hogy a nyelv majd magától odaképzel
Ez igaz, de csak azért, mert egy másik nyelv szabályai alapján próbálod használni a JS-t csak azért, mert hasonlít rá.
És ha odaképzeli, akkor tulajdonképpen le is szögezhetjük, hogy tkp. kötelező az, hisz a nyelv maga rakja oda
Nem, pont fordítva. Pont azért nem kötelező, mert a nyelv "odaképzeli" helyetted. Ha nem tenné akkor lenne kötelező.
Mert a
return
után az interpreter ugyanúgy kifejezést vár
Nem. A return után lehet kifejezés, de nem várja, hiszen nem kötelező az. Lehet return önmagában, indikálva azt, hogy undefined-dal akarsz visszatérni.
A további "így-úgy kellene lennie" részre azt tudom mondani: Szerinted, a te elvárásaid és más nyelvek által épített igényeid alapján.
Ismétlem magam, hogy nem tökéletes ahogy most van, lehetne szigorúbb, vagy könnyebben megérthető a működés. A problémám továbbra is az, hogy a megértést nem sikerült meglépned.
- A hozzászóláshoz be kell jelentkezni
> Nem akartam ennyire trollba átmenni, tényleg az hittem lehet értelmesen átbeszélni a témát.
A személyeskedést te kezdted, tehát te mentél át trollba magadtól. Az értelmes beszéd meg kb. ott ért véget, amikor kiköpted, hogy ez nem ésszerű, csak logikus. Bocs.
> Nem, a JS max közvetetten örökölte a C egyes nyelvi szabályait. Közvetlenül a JAVA-tól örökölt szintén nem mindent. Idézek a Wikipediából: "Netscape Communications then decided that the scripting language they wanted to create would complement Java and should have a similar syntax". Kiemelés tőlem.
És? Szintén Wikipédia a Java szintaxisáról: "The syntax is mostly derived from C and C++" A syntax layout (vezérlőszerkezetek, ciklusszervezés, blokkezelés, stb.) pl. szinte érintetlenül ment át a JS-be. És ez vonatkozik a többsoros utasításokra is.
> Ez igaz, de csak azért, mert egy másik nyelv szabályai alapján próbálod használni a JS-t csak azért, mert hasonlít rá.
Téves. Én a saját szabályai alapján használtam. Megengedi a többsoros utasítást? Meg. Akkor miről beszélsz?
> Nem, pont fordítva. Pont azért nem kötelező, mert a nyelv "odaképzeli" helyetted. Ha nem tenné akkor lenne kötelező.
Nem, pont fordítva (ülsz a lovon). A programozónak nem kötelező kiraknia, de az interpreternek kötelezően kell, ezért "képzeli oda". Ha nem tenné, akkor nem lenne kötelező.
> Nem. A return után lehet kifejezés, de nem várja, hiszen nem kötelező az. Lehet return önmagában, indikálva azt, hogy undefined-dal akarsz visszatérni.
Az rendben van, hogy a return
állhat önnmagában, de itt nem ez volt a helyzet. Volt utána egy kifejezés, csak épp baszott megkeresni, mert ahelyett, hogy abból indult volna ki, hogy itt biza állhat kifejezés és nincs a sor végén semmi, akkor menjünk tovább, jé, itt egy kifejezés, parsing-parsing-parsing és jé, itt az utasításterminátor, inkább bebaszott egy pontosvesszőt a végére. Nem ésszerűen, de logikusan. :)
> A további "így-úgy kellene lennie" részre azt tudom mondani: Szerinted, a te elvárásaid és más nyelvek által épített igényeid alapján.
Nem, ez nem "az én elvárásaim", hanem a logika ésszerűség alapján kéne így lennie.
> Ismétlem magam, hogy nem tökéletes ahogy most van, lehetne szigorúbb, vagy könnyebben megérthető a működés. A problémám továbbra is az, hogy a megértést nem sikerült meglépned.
Mit nem értettem meg? Hogy így működik? De, képzeld én ezt megértettem. Már akkor, amikor blr belinkelte azt a cikket. (Pontosabban: utána éjszaka esett le.) Napokkal azelőtt, hogy idejöttél.
Te viszont nem érted meg, hogy ahogy működik az egy önellentmondó baromság. Vagy mégis? Hiszen azt már beismerted, hogy ésszerűtlen. De azt tagadod, hogy önellentmondó. Ésszerűtlen, de nem önellentmondó? Akkor most...hogy is van ez? Ha nem önellentmondó, akkor mitől ésszerűtlen? Ráadásul erre a posztra direkt azért irányítottalak, hogy azt a bizonyos önellentmondást cáfold. Nos, nemhogy nem cáfoltad, de meg sem próbáltad cáfolni; teljesen más részeket ragadtál ki a posztból, pl. hogy most honnan is örökölte a szintaxist a nyelv, ami ebből a szempontból kb. annyira volt releváns, mint egy grillcsirke a hegesztésnél...
- A hozzászóláshoz be kell jelentkezni
Igazából nem fogunk napirendre jutni :)
- A hozzászóláshoz be kell jelentkezni
[GN]Dűlőre jutni, vagy napirendre térni; itt most az előbbi esedékes.[/GN]
A kérdés igazából már blr linkjével dűlőre jutott. A mi vitánk meg zátonyra futott, amikor ezt a logika != ésszerűség képletet felírtad. Onnantól már képtelen voltam komolyan venni.
- A hozzászóláshoz be kell jelentkezni
Semmi gond. A javítást is köszi, teljesen jogos :)
- A hozzászóláshoz be kell jelentkezni
Volt utána egy kifejezés
Szerinted. Csak épp semmivel nem jelezted a fordítónak, hogy a következő sorban lévő kifejezés a return sorában lévő kifejezéshez tartozik. Ha nem így lenne, hogyan kellene tudnia, hogy a masikkifejezes() már nem a returnhoz tartozik? Értem én, hogy szokatlan a ;-ző nyelvek után, de ez van.
if (false)
return
masikkifejezes()
- A hozzászóláshoz be kell jelentkezni
> Téves. Én a saját szabályai alapján használtam. Megengedi a többsoros utasítást? Meg. Akkor miről beszélsz?
Szerintem ebbe az is beletartozna, hogy tudsz rola, hogy az interpreter/fordito megprobal mindenhova pontosvesszoket biggyeszteni.
https://github.com/getify/You-Dont-Know-JS/blob/2nd-ed/types-grammar/ch…
Hiaba no, a JS az egyik legnehezebb programnyelv amit valaha tanultam. Csak a legtobb fejleszto ezt nem sejti.
- A hozzászóláshoz be kell jelentkezni
Ezen már több napja túl vagyunk. A hangsúly azon van, hogy ez, amit a JS csinál, egy nagy baromság.
- A hozzászóláshoz be kell jelentkezni
> egy nagy baromság.
Ebben egyet ertunk.
En a "a saját szabályai alapján használtam" reszt akartam kihangsulyozni, hogy egy kicsit fine-tune-olhassad a magabiztossag faktort.
- A hozzászóláshoz be kell jelentkezni
Nem a nagyképűsködés volt a cél, akkor átfogalmazom: megengedte, hogy ezt csináljam, tehát a szabályai szerint játszottam. Az más kérdés, hogy amit szerettem volna, azt a saját szabályai szerint nem így kellett volna. Ha tudom, nem csinálom így. Nem a forgalommal szembemenés volt a cél.
Footnote: Egyébként 16 évnyi JS után szerintem igazán nem a magabiztosságon múlik, ha valaki hulladéknak titulálja a JS-t, mint nyelvet és a böngészőkben futó JS implementációkat, hanem keserű tapasztalatokon. :(
- A hozzászóláshoz be kell jelentkezni
megengedte, hogy ezt csináljam, tehát a szabályai szerint játszottam
Ez egy helytelen következtetés. Egy dolog, hogy mit enged meg és mit nem, egy tök más, hogy amit megenged milyen eredményt produkál. A szabályok pedig mindkettőt meghatározzák, te pedig csak az elsőt hajtogatod :)
- A hozzászóláshoz be kell jelentkezni
Nem. Ötször leírtam már neked, vagy többször, hogy nem. Már a legelején tudomásul vettem, hogy ez így működik, csak nem tudtam róla és így elbasztam a kódot. Ettől még ez a konkrét szabály a másik - a többsoros utasítások megengedésének szabálya - mellé téve egy baromság, a nyelv pedig egy hulladék marad. Ez az, amit én hajtogatok, csak te nem akarod megérteni. Biztos, mert ez is csak ésszerű, de nem logikus.
- A hozzászóláshoz be kell jelentkezni
A kettővel fentebbi konkrét kijelentésedre reagáltam ami hibás volt, és amit most írtál semmiben nem cáfolja ezt.
- A hozzászóláshoz be kell jelentkezni
Nem volt hibás. A nyelv szabályai lehetővé tették, amit csináltam, tehát annak a szabályai szerint jártam el. Amit akartam, azt máshogy kellett volna, viszont ahogy kellett volna, az egy baromság. Nem tudom ennél világosabban leírni.
- A hozzászóláshoz be kell jelentkezni
Oké, egy shell script pedig lehetővé teszi, hogy kiadd az rm -rf / parancsot. Ha megteszed, akkor a shell a hülye?
- A hozzászóláshoz be kell jelentkezni
Nem baj, hogy almát hasonlítasz a döglött lóhoz? Egy szándékosan destruktív parancs végeredményét mosod össze azzal, hogy nem jó helyen volt az írásjel! Majd, ha a shell rm -rf kecske
helyett rm -rf kecske /
parancsot hajt végre, mert nincs a végén pontosvessző és ő önkényesen odavarázsol egy perjelet, majd akkor lesz hülye úgy, ahogy most hülye volt a JS. Jó (fals) kis érv csúsztatás volt, kis burkolt hülyézéssel megfejelve. Elfogytak az érvek, hogy már csak személyeskedésre futja?
Sz*rk: Egyébként nem tudom mit erőlködsz még két nap után is; nem tudom feltűnt-e, de ha másról nem is, arról közmegegyezés volt, hogy a JS-nek ezen húzása bizony jókora marhaság. Még te is azt mondtad, hogy nem ésszerű. Ha nem ésszerű a szabály, akkor én vagyok a hülye, mert nem tudtam róla, hogy van egy ésszerűtlen szabály és ésszerűséget feltételeztem?
- A hozzászóláshoz be kell jelentkezni
Megnéztem a linkelt előadást, jót röhögtem, köszönet :).
Ha nem válaszolnék kommentben, hát küldj privátot!
- A hozzászóláshoz be kell jelentkezni
function blacklisted(hostname)
{
var spl, hn;
spl = hostname.split(".");
if (spl.length >= 2)
{
hn = spl[spl.length - 2] + "." + spl[spl.length - 1];
return
(
(hn == "x.com") ||
(hn == "y.com") ||
(hn == "z.com")
)
;
}
else
{
return false;
}
}
undefined
console.log(blacklisted("x.com"));
function blacklisted(hostname)
{
var spl, hn;
spl = hostname.split(".");
if (spl.length >= 2)
{
hn = spl[spl.length - 2] + "." + spl[spl.length - 1];
return (
(hn == "x.com") ||
(hn == "y.com") ||
(hn == "z.com")
)
;
}
else
{
return false;
}
}
true
- A hozzászóláshoz be kell jelentkezni
OMG WUT? https://knowyourmeme.com/photos/173576-wat
Hans! ...
Bring ze Flammenwerfer! https://knowyourmeme.com/photos/1229782-this-is-a-flammenwerfer-it-werf…
- A hozzászóláshoz be kell jelentkezni
JS-ben nem kötelező az utasításokat lezárni egy ;-vel. Viszont mivel újsor karakter van a return után, így úgy van vele, hogy akkor az egy "return;"
- A hozzászóláshoz be kell jelentkezni
Szerintem a Javascript a lelke mélyéig el van qrva. https://9gag.com/gag/awom154
Szégyenletes hogy micsoda ellenmondások és érthetetlen konstrukciók vannak benne egymás hegyére hátára b.szkodva. All time kedvenc: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Globa… Ugye értjük? Beteszek egy string literált ami istibizti JS kód, majd végrehajtom. Tesztelhetőség rulz.
- A hozzászóláshoz be kell jelentkezni
100%-ig egyetértek. (Itt egy részletesebb tábla az anomáliákról, meg egy a typejuggling gyönyöreiről.)
Az eval()
az egy dolog, mert az csak egy lehetőség, amivel lehet élni, meg visszaélni, de az milyen már, hogy egy bad OOP move utáni állapottal lehet aritmetikai műveletet végezni? És az milyen, hogy az egyes műveletek a VM-implementációja szerint más-más eredményt adnak vissza? A JS kb. egyesíti az imperatív, az OOP és a funckionális nyelvek összes hátrányát. Ez a nyelv egy nagy inkonzisztens katyvasz.
- A hozzászóláshoz be kell jelentkezni
Erre az a triviális megoldás hogy nem használunk ==
-t soha. Mondjuk a PHP-hoz képest a kanyarban sincs.
- A hozzászóláshoz be kell jelentkezni
Szerintem egy normális programnyelvet nem úgy terveznek, hogy a véletlenül belekerült f.szságokra írunk egy "dont" listát.
- A hozzászóláshoz be kell jelentkezni
Egy normális programnyelvet lehet verziózni, a hibás funkciókat lehet deprekálni majd kivenni a nyelvből egy későbbi verzióban. Sajnos a JS nincs abban a helyzetben, hogy ezt megtehesse, csak olyan félmegoldások vannak mint a strict mode. Ami megoldás lehet az a fejlesztői eszközök használata mint a linterek és transpilerek, illetve transpileolt nyelvek (pl. TS), cserébe sokkal bonyolultabb összerakni egy JS projectet 0-ról.
- A hozzászóláshoz be kell jelentkezni
Nekem a JS mint intermediate language tökéletesen megfelel. Csak a fejlesztők ne abban gányoljanak, mert úgyis az lesz a vége. Ennek az egyetlen ellenszere ha eleve nincs lehetőség taknyolni.
- A hozzászóláshoz be kell jelentkezni
> Erre az a triviális megoldás hogy nem használunk ==
-t soha.
Na ja. Magyarán úgy csinálunk, mintha lennének típusaink, ahelyett, hogy lennének típusaink. :)
Azonfelül a ===
nem véd meg mindentől:
alert(null === null); // true
alert(Math.sqrt(-1) === Math.sqrt(-1)); // false
A kettőbe külön-külön is bele lehet kötni, bár meg is lehet magyarázni őket (elég erőltetetten), viszont együtt nézve a kettőt értelmezhetetlen a logika; a null
vagy undefined
állapotokat lehet értékként használni, míg a NaN
értéket meg nem?
> Mondjuk a PHP-hoz képest a kanyarban sincs.
Azt nem vitatom, hogy a PHP is egy überkókány nyelv, de a JS-sel azért messze többet lehet szívni. A PHP legalább egységesen ugyanúgy szar mindenütt, viszont a JS minden implementációban máshogy. :(
- A hozzászóláshoz be kell jelentkezni
A PHP legalább egységesen ugyanúgy szar mindenütt, viszont a JS minden implementációban máshogy.
A nap igazsága. :D
- A hozzászóláshoz be kell jelentkezni
A null a Null típus egyetlen példánya, az undefined az Undefined típusáé, egyik sem állapot. A NaN pedig az IEEE 754 miatt van így kezelve (lásd még: +0, -0, +Infinity, -Infinity).
- A hozzászóláshoz be kell jelentkezni
Mondtam, hogy külön még csak meg lehet magyarázni őket; együtt verik ki a biztosítékot. (Bár mondjuk az, hogy a null
és a undefined
az külön típus, az külön is kiveri a biztosítékot, lévén tkp. minden sikertelen objectekre hivatkozás ezeket eredményezi, tehát akkor egy objektummal végzett művelet három típust is eredményezhet.)
- A hozzászóláshoz be kell jelentkezni
A kettő teljesen mást reprezentál. Az undefined a unit típus JS megfelelője, a null a null referenciáé. Az egyik azt jelenti hogy nincs érték, a másik azt hogy van érték de más információ nem érhető el. Arról lehet vitatkozni, hogy a különböző APIk mikor melyiket kellene, hogy használják, de a nyelv konzisztensen használja a kettőt (kivéve a typeof operátor, de annak több hibája is van).
- A hozzászóláshoz be kell jelentkezni
> Az egyik azt jelenti hogy nincs érték
Erről beszélek, hogy adott egy típus, aminek az értéke, hogy nincs érték. Úgy, hogy ennek nem értéknek kéne lennie, hanem állapotnak.
> de a nyelv konzisztensen használja a kettőt
De rosszul.
Azonfelül, mint mondtam a ===
nem véd meg mindentől:
alert(Math.pow(Math.random(), document.getElementById("no_such_element"))); // <= will alert 1
- A hozzászóláshoz be kell jelentkezni
Azért ez nem egy ördöglakat.
- A hozzászóláshoz be kell jelentkezni
Nem, ez egy masszív logikai bukfenc, ami épeszű fejlesztő fejében meg sem fordul, hogy ennek így kéne működnie.
- A hozzászóláshoz be kell jelentkezni
Mondanám, hogy annak aki tudja, hogy a js-ben félig meddig opcionális a ";", azoknak eszébe jut, de nekem se jutott, pedig próbáltam így is úgy is js-ezni.
Ha nem válaszolnék kommentben, hát küldj privátot!
- A hozzászóláshoz be kell jelentkezni
Mi az, hogy félig-meddig opcionális? :))) Hogy lehet egy nyelvben bármi félig-meddig opcionális? Vagy az, vagy nem az. Olyan nincs, hogy is-is. Ja de, JS-ben. :P
Ezt írtam le a fentebbi posztban, hogy ez nettó agyhalál, hogy egyszerre van lehetőség a multi-line utasításra és igény a sorvégi pontosvesszőre, mert ez két egymásnak ellentmondó dolog.
- A hozzászóláshoz be kell jelentkezni
Tudsz olyan js programot írni, ami ugyan úgy működik, ha van és ha nincs benne ";", akkor is. Tudsz olyan programot írni, ami teljesen különbözően működik, nem dob hibát a parser, és ezért félrevezető. Erre jó megfogalmazásnak találtam a "félig-meddig". A másik szó tényleg az agyrém :).
Ha nem válaszolnék kommentben, hát küldj privátot!
- A hozzászóláshoz be kell jelentkezni
> Tudsz olyan js programot írni, ami ugyan úgy működik, ha van és ha nincs benne ";", akkor is. Tudsz olyan programot írni, ami teljesen különbözően működik, nem dob hibát a parser, és ezért félrevezető.
Na jó, de erre írtam, hogy ha az interpreter "belehamisítja" a kódba a pontosvesszőt, akkor mégis csak kéne bele, tehát nem opcionális.
- A hozzászóláshoz be kell jelentkezni
Nem belehamisítja. Egyszerűen egy utasítás akkor számít lezártnak, ha benne a zárójelek, idézőjelek lezártak, és vagy pontosvessző következik, vagy pedig sortörés néhány esetet leszámítva, pl a köv sor plusszal vagy mínusszal kezdődik.
Ez tényleg nem annyira triviális, de azért nem is ördögtől való :) Valahogy meg meg kell oldani, ha az a cél, hogy ne kelljen pontosvesszőt írni. Mi volna a te javaslatod?
- A hozzászóláshoz be kell jelentkezni
Idézőjelekben volt a hamisítás.
Az volna a javaslatom, hogy kötelező legyen a pontosvessző, ahogyan az várható lenne. De ezt leírtam már.
- A hozzászóláshoz be kell jelentkezni
Jogos az idézőjel :)
Én örülök, hogy nem kötelező, legalább is nyelvi szinten. Te preferálod, én pedig nagyon szeretem a pontosvesszőket teljesen nélkülöző kódot, jó ránézni. Így, hogy opcionális, megfelelő linter beállítással lehet bolondbiztos és szép egységes kódot írni mindkettőnk számára.
- A hozzászóláshoz be kell jelentkezni
Mit értesz "mindkettőnk" alatt? Téged és a lintert?
- A hozzászóláshoz be kell jelentkezni
Téged, mint pontosvesszőt akarót, és engem, mint nem akarót :)
- A hozzászóláshoz be kell jelentkezni
Ha két ellentétes dolgot akarunk, akkor hogy írsz mindkettőnknek megfelelő kódot? Első dolgom az lenne, hogy mindenhova beteszem a pontosvesszőket...aztán ha a pontosvesszők hiánya miatt rosszul értelmezem a kódodat, akkor még el is cseszem vele. :P
- A hozzászóláshoz be kell jelentkezni
Félreértetted: Nem írok mindkettőnknek megfelelő kódot. Arra akartam rávilágítani, hogy én tudok olyat írni, ami nekem jó, és te is tudsz olyat írni, ami neked jó, mert a nyelv mindkettőnknek lehetővé teszi ezt.
- A hozzászóláshoz be kell jelentkezni
Na ja, csak az én kódom a nyelvnek nem volt jó. Magyarán akkor a nyelv csak neked teszi lehetővé, hogy olyan kódot írj, amilyet akarj, mert az enyémet nem ette meg.
- A hozzászóláshoz be kell jelentkezni
Arra gondoltam, hogy írhatsz pontosvesszőt a sorok végére.
De mégis mit szeretnél? Szembepisilni a nyelv szintaxisát, és elvárni, hogy úgy működjön, ahogy te képzeled?
- A hozzászóláshoz be kell jelentkezni
> Arra gondoltam, hogy írhatsz pontosvesszőt a sorok végére.
Többsoros utasításban minek tennék a sorok végére pontosvesszőt? Én nem erről beszéltem.
> De mégis mit szeretnél? Szembepisilni a nyelv szintaxisát, és elvárni, hogy úgy működjön, ahogy te képzeled?
Jó reggelt kívánok, szintaktikailag helyes volt, különben errort dobott volna. Én nem képzelek semmit, ez lett volna a logikus.
- A hozzászóláshoz be kell jelentkezni
Igazad van mindkét esetben, pontatlanul fogalmaztam:
- Az utasítás végére tehetsz pontosvesszőt
- Szintaktikailag helyes, viszont a kódod hibás. Ez is helyes szintaktikailag 2/5. Más nyelveken viszont más eredményt ad. Ismerned kell a nyelvet, a típuskonverziós szabályait hogy tudd, hogy mi lesz az. Pont erről beszélek.
- A hozzászóláshoz be kell jelentkezni
> Az utasítás végére tehetsz pontosvesszőt
És akkor esetleg a topicindító probléma jön elő.
> Szintaktikailag helyes, viszont a kódod hibás.
Igen, hibás, de miért? Mert a JS logikája saját magának mondott ellent.
- A hozzászóláshoz be kell jelentkezni
Amúgy de, a kódodat megette és értelmezte a nyelv szabályai szerint. Egyszerűen a kódod volt hibás.
- A hozzászóláshoz be kell jelentkezni
> Amúgy de, a kódodat megette és értelmezte a nyelv szabályai szerint. Egyszerűen a kódod volt hibás.
GOTO10, nem érted, hogy két egymásnak ellentmondó dologról beszélünk (többsoros utasítás vs. sorvégi utasításlezárás)? A kód hibás volt, az tény, de nem azért, mert a gondolatmenet hibás, hanem mert a JS "logikája" az.
- A hozzászóláshoz be kell jelentkezni
két egymásnak ellentmondó dologról beszélünk (többsoros utasítás vs. sorvégi utasításlezárás)
Tökéletesen értem. Mire alapozod a kijelentésedet, miszerint ez egymásnak ellent mond?
És miért idézőjeles a nyelv logikája? Valami nem attól lesz logikátlan, hogy nem értesz vele egyet. Van logikája, más kérdés, hogy szimpatikus-e vagy sem, illetve jó dolog-e vagy sem.
- A hozzászóláshoz be kell jelentkezni
> Tökéletesen értem. Mire alapozod a kijelentésedet, miszerint ez egymásnak ellent mond?
Jó ég... Ha egy utasítás lehet többsoros, akkor hogy lehet, hogy a nyelv önhatalmúlag utasításlezárást injektál a sorok végére? Még mindig nem érted, hogy két egymásnak ellentmondó mechanizmus működik itt párhuzamosan?
> És miért idézőjeles a nyelv logikája? Valami nem attól lesz logikátlan, hogy nem értesz vele egyet. Van logikája, más kérdés, hogy szimpatikus-e vagy sem, illetve jó dolog-e vagy sem.
A logika nem szimpátia kérdése, könyörgöm... Olvasd már el ezt a posztot és próbáld meg megérteni, hol van a JS értelmezésében a logikai bukfenc.
- A hozzászóláshoz be kell jelentkezni
Ha egy utasítás lehet többsoros, akkor hogy lehet, hogy a nyelv önhatalmúlag utasításlezárást injektál a sorok végére?
Miért következne egyikből a másik? A nyelv nem minden sor végén végez önhatalmú utasításlezárást, hanem bizonyos feltételek mellett. Amikor ezek a feltételek nem teljesülnek akkor az utasítás folytatódik a következő sorban.
A logika nem szimpátia kérdése, könyörgöm
Én is ezt mondom. Btw a köznyelv keveri a logikus és az ésszerű szavakat. Pl mondhatod, hogy nem ésszerű ahogy a JS működik, és ezzel tudok akár egyet is érteni. De ettől még logikus, hiszen egy logikai rendszer határozza meg a működését.
Elolvastam. Kommenteljem is? Több ponton tévedésekkel van tele.
- A hozzászóláshoz be kell jelentkezni
> Miért következne egyikből a másik? A nyelv nem minden sor végén végez önhatalmú utasításlezárást, hanem bizonyos feltételek mellett. Amikor ezek a feltételek nem teljesülnek akkor az utasítás folytatódik a következő sorban.
És ezeket a feltételeket sikerült a legostobább módon, a logika teljes mellőzésével összerakni. Komolyan egy zárójel pozícióján múlik, hogy jó-e vagy sem? Ráadásul nem is errort dob, hanem error nélkül kiszáll hibás működéssel?
> Én is ezt mondom. Btw a köznyelv keveri a logikus és az ésszerű szavakat. Pl mondhatod, hogy nem ésszerű ahogy a JS működik, és ezzel tudok akár egyet is érteni. De ettől még logikus, hiszen egy logikai rendszer határozza meg a működését.
Kész, én már beszarok rajtad, komolyan. :))) Nem ésszerű, de logikus? Hát...logikus, hogy ez nem ésszerű...de attól még logikus, mert egy ésszerűtlen logikai rendszer határozza meg! Kész... :)
> Elolvastam. Kommenteljem is? Több ponton tévedésekkel van tele.
Go ahead. Make my evening. :)
- A hozzászóláshoz be kell jelentkezni
És ezeket a feltételeket sikerült a legostobább módon, a logika teljes mellőzésével összerakni.
Lehet. De ettől még léteznek, meg vannak határozva, és be is vannak az implementáció által tartva. Ettől lesz logikus, nem attól, hogy számodra nem ésszerű vagy neked nem tetszik.
hanem error nélkül kiszáll hibás működéssel
Welcome to the JS world :)
Nem ésszerű, de logikus?
Leírtam miért.
- A hozzászóláshoz be kell jelentkezni
> Lehet. De ettől még léteznek, meg vannak határozva, és be is vannak az implementáció által tartva. Ettől lesz logikus, nem attól, hogy számodra nem ésszerű vagy neked nem tetszik.
Értem... :) Tehát te egy ésszerűtlen "logikát" próbálsz meg mindenáron körmödszakadtáig védeni.
> Welcome to the JS world :)
I don't feel so welcomed. Surely 'cause JS is Just Shit.
> Leírtam miért.
Ja. Le. Be kéne keretezni. :)
- A hozzászóláshoz be kell jelentkezni
Nem védek semmit. Sok szempontból én sem szeretem a nyelvet. Ettől még elfogadom, hogy ha én használom rosszul, - még ha az ésszerűbbnek is tűnik számomra - akkor nem a nyelvvel van baj.
- A hozzászóláshoz be kell jelentkezni
Az attól függ, hogy mit értesz "rossz használat" alatt. Ha elrontod a kódot, akkor nem a nyelvvel van a baj. De itt a nyelvben volt egy bazi nagy ésszerűtlenség, vagyis a nyelvvel van a baj.
- A hozzászóláshoz be kell jelentkezni
Rossz használat alatt azt értem, hogy a nyelv szabályai szerint két utasítást (egy üres return-t, és egy különálló kifejezést) írsz le, holott nem ez állt a szándékodban.
- A hozzászóláshoz be kell jelentkezni
Ebben az értelmezésben rossz használat. De ettől még a nyelv idevágó szabályai logikátlanok ésszerűtlenek. Vagyis rossz használat, vagy sem; a nyelvvel van a baj. Illetve nem is a nyelvvel van a baj, ez a nyelv maga a baj.
- A hozzászóláshoz be kell jelentkezni
Aha, azért még érdemes megnézni a C szabványt is, hogy mennyi mindent bíz a fordító implementációjára. Komplett kódolási szabványok születtek ezek korrigálására (pl. az autóiparban is használt MISRA C).
- A hozzászóláshoz be kell jelentkezni
Azért bukfenc neked, mert úgy gondoltad, hogy azért, mert úgy indentáltad a kódot, hogy úgy nézzen ki, mintha a return után lenne akkor az ott is van, pedig nem. Épeszű embernek eszébe sem jutna így írni a kódot!
- A hozzászóláshoz be kell jelentkezni
> Azért bukfenc neked, mert úgy gondoltad, hogy azért, mert úgy indentáltad a kódot, hogy úgy nézzen ki, mintha a return után lenne akkor az ott is van, pedig nem.
Nem, nem nekem bukfenc, olvasd el a fentebbi posztot és értelmezd. Lehet cáfolni a levezetést.
> Épeszű embernek eszébe sem jutna így írni a kódot!
Tényleg? Szerintem meg ez egy teljesen valid indentálás, hogy ne egy baromi hosszú sor legyen; szerintem ez egy épeszű megközelítés. Azonfelül egy többsoros utasításokat engedő nyelvben a zárójel pozíciójának irrelevánsak kéne lennie, szerintem ez egy épeszű vélemény.
Ezek után miért nem vagyok én épeszű? Mi okod van a személyeskedésre, áruld már el...
- A hozzászóláshoz be kell jelentkezni
Mi számít többsoros utasítást engedő nyelvnek? A Python az? Lehet benne ilyet írni, mégsem teheted oda a zárójelet, ahova szeretnéd.
Amire te utalsz azok azok a nyelvek, ahol a pontovessző kötelező, ott tényleg oda rakod a zárójelet, ahova akarod.
- A hozzászóláshoz be kell jelentkezni
Nem ismerem a Pythont. Ezt is leírtam már. Többsoros utasítást engedő nyelvnek az számít, ahol az utasítást leírhatod több sorban. Nem tudom mi nem egyértelmű ezen. Pl.:
int
i
=
1
;
Csakhogy az nem megy, hogy egyszerre lehet többsoros az utasítás, az utasítást terminálni meg nem kötelező, majd megteszi az ember helyett a nyelv. De ezt is leírtam már.
- A hozzászóláshoz be kell jelentkezni
Egyértelmű. De az is több soros utasítást engedő nyelv, ami ezt megkötésekkel teszi. Ilyen a JS és a Python is. Amit te írsz, az csupán annyi, hogy kevesebb (nincs?) megkötés abban hova raksz sortörést.
- A hozzászóláshoz be kell jelentkezni
De bakker, leírtam, hogy a kettő egyszerre nem megy. Nincs olyan, hogy engedem a többsoros utasítást, aztán meg sorvégi pontosvesszőket szúrok be önhatalmúlag...
- A hozzászóláshoz be kell jelentkezni
Látod, hogy van, és működik. Nézd. Nem biztos, hogy ez jó dizájn, de az alapvető probléma, hogy néhány logikus szabályt kell csak megérteni és megtanulni. Ez elvárható valakitől, aki egy adott nyelv szakemberének képzeli magát, nem?
- A hozzászóláshoz be kell jelentkezni
> Látod, hogy van, és működik.
ROFL... Az egész topic abból indult ki, hogy nem működik.
> Nem biztos, hogy ez jó dizájn, de az alapvető probléma, hogy néhány logikus szabályt kell csak megérteni és megtanulni.
A probléma nem az, hogy szabályokat kell megtanulni, hanem, hogy ezek a szabályok éppenhogy nem logikusak, hanem önellentmondóak. Valamint nem néhány ilyenről beszélünk, hanem egy hadseregnyiről. Azonfelül most akkor nem jó a dizájn, vagy igen?
> Ez elvárható valakitől, aki egy adott nyelv szakemberének képzeli magát, nem?
Aki csak képzeli egy adott nyelv szakemberének magát, attól semmi sem várható el. Baromságok megtanulása és megértése pedig senkitől nem várható el.
- A hozzászóláshoz be kell jelentkezni
Az egész topic abból indult ki, hogy rosszul használod a JS-t, nem ismered azt a pár szabályt, ami meghatározza mit tart a JS motor egy statementnek. Magyarul rosszul használod, és nem megérteni akarod, hanem fikázni.
hanem, hogy ezek a szabályok éppenhogy nem logikusak, hanem önellentmondóak
Fejtsd ki kérlek, miben valósul meg az önellentmondás.
Baromságot nem kell megtanulnod, van több választásod: Nem használod a nyelvet, transpileren keresztül használod, vagy beállítasz egy lintert, ami fogja a kezed, hogy ne tudd elrontani. Mi mást akarsz? A nyelv alkalmazkodjon hozzád? Sokkal több opció nincs.
- A hozzászóláshoz be kell jelentkezni
> Az egész topic abból indult ki, hogy rosszul használod a JS-t, nem ismered azt a pár szabályt, ami meghatározza mit tart a JS motor egy statementnek. Magyarul rosszul használod, és nem megérteni akarod, hanem fikázni.
Mintha leírták volna többen is, hogy nincs megegyezés abban, hogy kötelező legyen-e, vagy sem. Akkor milyen szabályról beszélsz? A szabály hiányáról beszélhetsz, maximum. Ami pedig a fikázást illeti, csak azt tudom neked mondani, amit kb. egy éve is.
> Fejtsd ki kérlek, miben valósul meg az önellentmondás.
RTFT, ötvenszer leírtam már.
> Nem használod a nyelvet, transpileren keresztül használod, vagy beállítasz egy lintert, ami fogja a kezed, hogy ne tudd elrontani. Mi mást akarsz? A nyelv alkalmazkodjon hozzád?
Ezek közül a linter opció egyedül, azon meg már két napja túl vagyunk; kösszép. Senki nem kérte, hogy a nyelv alkalmazkodjon hozzám, csak felróttam egy baromságot. Mi fáj?
- A hozzászóláshoz be kell jelentkezni
Nagyon kevered a dolgokat.
Abban nincs általános megegyezés, hogy te mint programozó leírd-e a pontosvesszőt, vagy sem. A szabály amiről beszélek az ECMAScript Language Specification pedig pontosan meghatározza hogy kell a sortöréseket értelmezni.
csak azt tudom neked mondani, amit kb. egy éve is.
Képes voltál egy éves kommenteket visszakeresni hogy legyen muníció a személyeskedéshez? Más okod mi lehetett rá?
RTFT, ötvenszer leírtam már.
Amit leírtál az nem bizonyít ellentmondást.
Mi fáj?
Semmi sem, beszélgetünk egy témáról amiről eltérő véleményeink vannak. Bár kezd fájni az, hogy nem látod be hol sántít az érvelésed. Fentebb pl összemostad a kódolási szabályokat a nyelvi szabályokkal. De nyilván elmondod miért tévedek mindjárt.
- A hozzászóláshoz be kell jelentkezni
> A szabály amiről beszélek az ECMAScript Language Specification pedig pontosan meghatározza hogy kell a sortöréseket értelmezni.
Az ECMAScript egy papíron lévő dolog, a JS meg a böngészőben lévő. Az N féle JS implementáció M féleképpen szarja le az ECMAScriptet.
> Képes voltál egy éves kommenteket visszakeresni hogy legyen muníció a személyeskedéshez? Más okod mi lehetett rá?
Nem kerestem vissza, emlékeztem rá. Amúgy személyeskedni akkor is és most is te kezdtél el, ld. még "szakembernek képzeli magát", "csak fikázni akarod", stb.
> Amit leírtál az nem bizonyít ellentmondást.
De igen. Csak te nem akarod belátni.
> Semmi sem, beszélgetünk egy témáról amiről eltérő véleményeink vannak. Bár kezd fájni az, hogy nem látod be hol sántít az érvelésed. Fentebb pl összemostad a kódolási szabályokat a nyelvi szabályokkal. De nyilván elmondod miért tévedek mindjárt.
Nem, nem írom le többször. Elég volt. Az előbb belinkeltem, hogy hol volt részletesen kifejtve. Próbáld meg megérteni.
- A hozzászóláshoz be kell jelentkezni
Az N féle JS implementáció M féleképpen szarja le az ECMAScriptet
Ez igaz, de ez nem a nyelv hibája. A nyelv az, amit a specifikációban látsz. A böngészők implementációja pedig meglepően sok dologban tartja ezt, amit írsz pedig eléggé a múlté.
d. még "szakembernek képzeli magát", "csak fikázni akarod", stb.
Az első nem neked szólt, a második pedig egy feltételezés. Ha téves szólj, de feltételezem mások is hasonló konzekvenciát vonnának le ebből.
Csak te nem akarod belátni.
Nem akarat kérdése. Lehet hogy csak buta vagyok, és nem sikerül megértenem :)
Próbáld meg megérteni.
Na, akkor itt van a kutya elásva: Nem a megértés a probléma, hanem az, hogy amit írsz az nem jó.
- A hozzászóláshoz be kell jelentkezni
Jaja, mar majdnem python-szintu :) Bar ott az elemi muveletekkel meg a sztringekkel is gondok vannak.
- A hozzászóláshoz be kell jelentkezni
> Jaja, mar majdnem python-szintu :)
A Pythont mint nyelvet elég felületesen ismerem, nem tudom mik a buktatói, mert a "whitespace matters" filozófia elég volt arra, hogy inkább kihagyjam...
> Bar ott az elemi muveletekkel meg a sztringekkel is gondok vannak.
- A hozzászóláshoz be kell jelentkezni
apal@laptop:~$ python
Python 2.7.13 (default, Sep 26 2018, 18:42:22)
[GCC 6.3.0 20170516] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> print(5/2)
2
>>>
apal@laptop:~$ python3
Python 3.5.3 (default, Sep 27 2018, 17:25:39)
[GCC 6.3.0 20170516] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> print(5/2)
2.5
>>>
Biztos rendkivul izgalmas lesz amikor a python2 mar nem lesz becsomagolva :)
- A hozzászóláshoz be kell jelentkezni
Fő a backward compatibility. :/ (Egy nagy lábosban.)
Meg a typejuggling is nagy rulez...
- A hozzászóláshoz be kell jelentkezni
Nem az a baj hogy gyengen tipusus, hanemhogy ez igy megvaltozik. Bizonyara a szokoz vs. tab ertelmezes is finomhangolodik a ket verzio kozott ;]
- A hozzászóláshoz be kell jelentkezni
Most lecsekkoltam és az 5.0/2.0 az 2.5-öt eredményez Python2-ben, ahogy az ember várná. Ezt tényleg kár volt lecserélni; az is egy logika, hogy egészek közti művelet egészet fog eredményezni, ott meg nincs tizedes.
Ami a szóköz/tabot illeti nem tudom és nem is akarom tudni; nem nekem találták ki a whitespace-sensitive nyelveket. :/ (De az már tényleg agyhalál lenne, ha még a tab meg a space közt is különbséget tennének.)
- A hozzászóláshoz be kell jelentkezni
Van valamilyen standard, ami legalább ezeket a quirk-nek tűnő jelenségeket leírja, hogy hogy kéne lennie? Amíg le nem írtad, hogy egészek közti művelet, addig nem jutott eszembe így megfogalmazni (maximum egész számokon végzett műveletként, de őszintén nem tudom milyen nyelvben van szabályozási lehetőség erre), a fentebb linkelt előadásban is elhangzik, hogy van amire a typerror és egy másik végkifejlet is jó megoldás, jó lenne egy irányelv erre :).
Ha nem válaszolnék kommentben, hát küldj privátot!
- A hozzászóláshoz be kell jelentkezni
Erre sajnos érdemben nem tudok válaszolni, mert Pythont én maximum buildkörnyezetben látok.
- A hozzászóláshoz be kell jelentkezni
Van valamilyen standard, ami legalább ezeket a quirk-nek tűnő jelenségeket leírja, hogy hogy kéne lennie?
Persze van, de pont az a lenyeg hogy a python mint programozasi nyelv valtozik meg ilyen szinten (i.e. elemi muveletek szintjen) ha ezeket menetkozben valtoztatod. Az 5.0 float, az 5 egy egesz, az 5e0 megint float, a 0x5 megint egesz. Kicsit kesobb meg mar az 5 is egy float lesz. Kiveve ha //-rel osztod. Mert akkor egesz. Sot, a 5.0 is egy egesz, ha //-vel osztod, de akkor az 5.//2 eredmenye 2.0 lesz!
Dehat ilyen ez a popszakma ha gyengen tipusos nyelvvel dolgozik az ember...
- A hozzászóláshoz be kell jelentkezni
A Python 2 már nem támogatott. Amit nem portoltak 3-as alá, azt szépen békén kell hagyni és fusson nyugodtan 2-es alatt, ameddig megszűnik a cég/kihal a gép alóla. Aki akart, már átállt 3-as alá, és az ilyesmi hibák előjöttek az unittesztek során.
- A hozzászóláshoz be kell jelentkezni
ESLint egyből kiszúrja, tessék lintert használni.
10:4 - Unreachable code. (no-unreachable)
Sőt, még a Firefox konzolja is.
Figyelmeztetés: unreachable code after return statement [További tudnivalók]
- A hozzászóláshoz be kell jelentkezni
> tessék lintert használni
Shellből nodejs-t meghívva validáltattam a kódot, az nem reklamált ilyenért. (cat x.js | nodejs -c
) De kösz a tippet.
> Sőt, még a Firefox konzolja is.
Az meg nem szúrt ki az ég egy adta világon semmit sem. Lefutott és nem reklamált, csak épp undefined
-et adott vissza.
- A hozzászóláshoz be kell jelentkezni
A node.js nem linter, ha a browser nem szól érte akkor az se fog. A Firefox-os példához hozzátartozik hogy a konzolba másoltam be a kódot, lehet hogy azért szólt.
- A hozzászóláshoz be kell jelentkezni
> A node.js nem linter, ha a browser nem szól érte akkor az se fog.
Ack. Nekem CLI-s kellett, de akkor majd keresek tovább.
> A Firefox-os példához hozzátartozik hogy a konzolba másoltam be a kódot, lehet hogy azért szólt.
Nope. Most én is becopyztam és nem szólt egy szót sem.
- A hozzászóláshoz be kell jelentkezni
Meghagyva a logikádat ez kb így néz ki 2020-ban írva:
const blacklisted = (hostname) => {
const spl = hostname.split('.');
if (spl.length >= 2) {
const hn = `${spl[spl.length - 2]}.${spl[spl.length - 1]}`;
return (hn === 'x.com') || (hn === 'y.com') || (hn === 'z.com');
}
return false;
};
Ugye hogy mennyivel olvashatóbb? Persze ezen lehetne javítani, pl dobjuk a logikád. :D
- A hozzászóláshoz be kell jelentkezni
A példában 3 feltétel volt, de mi van, ha 30 van? Azt is egy sorba írod? 2020 meg le van szarva, engem az érdekel mi fut a böngészőben és ez nem fog mindegyikben lefutni. (Nézd meg milyen szépen kiszínezte a Firefox: http://oscomp.hu/depot/js2020.png) A hn
értékadó sora pedig minden, csak nem olvasható.
Úgyhogy nem az én logikámat kell eldobni. (Inkább a JS-t kéne, ha lehetne.)
- A hozzászóláshoz be kell jelentkezni
nem fog mindegyikben lefutni - de minden modernben, netán ie-re fejlesztesz? (ha igen -> babel)
Linterem nem színezi ki a tied ne tudom hol veszett el. :P
Gondoltam, hogy leírom de elmaradt. így szokás:
return (hn === 'x.com')
|| (hn === 'y.com')
|| (hn === 'z.com');
Viszont mivel ez egy dinamikus lista lenne célszerűbbnek tűnik így:
return blacklistedDomains.includes(hn);
- A hozzászóláshoz be kell jelentkezni
> de minden modernben, netán ie-re fejlesztesz?
Nem konkrétan IE-re, de úgy, hogy minél több böngészőben menjen. Mert nem mindenütt van modern böngésző. Főleg cégeknél van olyan, hogy valami régebbi cucc van. Volt rá precedens, hogy egy beágyazott rendszer webes felületét csináltam, amire kellett AJAX, meg pár egyéb funkció. ES3 compliant módon csináltam meg, hogy a legtöbb helyen menjen. Ment. Még Netscape-ben is. (Na jó, IE6-ban nem mertem megpróbálni. :P )
> Gondoltam, hogy leírom de elmaradt. így szokás:
Bocs, de ezt így kategorikusan kijelenteni, hogy ez így szokás, az azért kicsit fals. Én általában a BSD-k által favorizált Allman style-t követem, az pedig új sorba és indentálva rakja a blokknak az első sorát (is). Tehát ahány ház, annyi szokás.
De amúgy az megvan, hogy most megint kódstílusból akarjuk megkerülni a nyelv agyhalottságát? Azt kéne végre megérteni, hogy egy többsoros utasításokat támogató nyelvben a kifejezés részei sorfüggetlenül "lebegnek" és vezérlőtől utasításlezáróig terjednek! A JS pedig összekeveri az egysoros és a többsoros megközelítést, amiből ilyenek születnek. Az a nyelv, amit egy másfajta kódstílussal fel lehet borítani, az nem ér egy vödör vizet sem... És ez nem "2020" kérdés.
- A hozzászóláshoz be kell jelentkezni
ktkt által javasolt módszer IE9-kompatibilis változata:
return blacklistedDomains.indexOf(hn) !== -1
Ha IE6-ra kéne fejleszteni, akkor egyrészt az a véleményem, hogy sóval be kéne hinteni a helyet (miután hidrogénbomba találat érte), illetve csak megfizetnek annyira, hogy a JS okozta bántalmaidat egy tengerparton kipihenhesd. :)
- A hozzászóláshoz be kell jelentkezni
De mondom, hogy nem IE. :) Mondjuk az indexOf
-nak működnie kéne majd' mindenütt, de az a baj, hogy ez nem ilyen egyszerű, mert nem sima lista, lehet, hogy komplexebb kapcsolatok is lesznek, mint az, hogy valamelyik az N-ből.
Az IE összes verzióját le kéne bombázni, majd plutóniummal behinteni, ebben egyetértünk. De attól, hogy az IE is trágya, attól még a JS is az marad.
- A hozzászóláshoz be kell jelentkezni
Az IE6/jQuery időkben egyébként én is eléggé utáltam a JS-t, pl. a sok function(function(){}){}
féle kódok, meg a 48 emeletes callback-hell miatt. Mára azonban sokat fejlődött, olvashatóbbá vált a szintaktikája az ES6 elemekkel, meg hamarosan jön még pár újabb is, pl. a pipeline-operátor (|>), meg az optional-chaining: obj.first?.second; Illetve a mai modern frameworkökkel (pl. Vue), már egész kényelmes dolgozni.
- A hozzászóláshoz be kell jelentkezni
Hát ha a modernebb szintaktika alatt azt kell érteni, amit ktkt mutatott (const hn = `${spl[spl.length - 2]}.${spl[spl.length - 1]}`;
) ez éppenhogy nehezebben olvasható. Mintha a JS eddigi katyvaszát nyakonöntötték volna még egy kis shellscriptinggel is és ránézvén az általad említett pipeline operátorra, még inkább ez a véleményem. Eddig csak a procedurális, funkcionális és OOP nyelvekből volt összevasvillázva mindenféle, de most még a shellscriptingből is lesz? Nem elég karácsonyfa még ez a nyelv? Csak mert így most már N féle szintaktikája és M féle szemantikája lesz a nyelvnek, ami aztán végképp nem azt fogja eredményezni, hogy ez könnyen olvasható, értelmezhető és debuggolható lesz...
A Vue-t nem ismerem. De az eddigi JS frameworkök után valahogy ehhez sincs bizodalmam.
- A hozzászóláshoz be kell jelentkezni
A pipe operátor több funkcionális nyelvben is van, pl. F#, nem csak shellben létezik.
A template stringek jók, a probléma itt inkább az hogy nincs is szükség erre a te függvényedben. Használhatnál pl. regexpet a megfelelő substring kiválasztásához:
const blacklistedDomains = new Set([
'x.com',
'y.com',
'z.com'
]);
function blacklisted(hostname)
{
const [ domain ] = hostname.match(/[^.]+\.[^.]+$/) || [];
return blacklistedDomains.has(domain);
}
Nyilván a Set lecserélhető sima tömbre vagy objektumra (ahol az objektum kulcsai az értékek), az array destructuring helyett lehet indexelni, stb.
- A hozzászóláshoz be kell jelentkezni
> A pipe operátor több funkcionális nyelvben is van, pl. F#, nem csak shellben létezik.
Oké, de itt nem magával a pipe operátorral volt a baj, hanem azzal, hogy a JS egyre többféle megközelítést lapátol össze. Most akkor ez egy OOP nyelv, procedurális, vagy funkcionális? Egyszerre mind. És rosszul. (Amúgy amit ktkt mutatott értékadást, az kiköpött shellscript volt.)
> Használhatnál pl. regexpet a megfelelő substring kiválasztásához:
És az mennyivel lesz lassabb, mint a sima logikai kapcsolatok halmaza? Ja és még egyszer: nem biztos, hogy ez sima lista marad, lehet, hogy komplexebb összeüggés is lesz az egyes domainok között.
- A hozzászóláshoz be kell jelentkezni
Akkor úgy tűnik, csak más az ízlésünk a szintaktika terén. A JS template string-ek számomra olvashatóak, mivel Python 3.6-ból is az f-string elem lett a kedvencem, ami nagyon hason ehhez, kompakt kifejezéseket lehet vele írni: f"Helló {nev}!"
. Nagyobb kedvvel írok JS-ben ilyet, mintsem a régi változatot: 'valami ' + egy_valtozo + ' valami más'
. Az már a szerkesztő feladata, hogy megfelelően kiszínezze a változókat, a kifejezésben.
Azt én nem tartom feltétlenül hátránynak egy programnyelvnél, ha többféle paradigmát is támogat. Ki kell választani a neked tetsző stílust és azt használni. Szvsz nem baj ha egy nyelv fejlődik, lesznek benne új elemek, még úgy is, hogy emiatt egy adott feladatra két módszer is lesz (pl. Python-ban az f-sztringek előtt már volt két másik módszer is sztring-interpolációra). Majd kialakul, hogy melyiket használják a gyakorlatban. JS-ben ilyen volt pl. az async-await, ami a callback-hellre adott egy sokkal áttekinthetőbb alternatívát.
- A hozzászóláshoz be kell jelentkezni
Hát eléggé más; én az oldworld procedural nyelvektől jövök, meg az ASM-től, így én pont a régi, egyértelmű változatot preferálom.
Na ja, ha rend van tartva és egyféle paradigma szerint kódolnak az emberek, akkor működhet a dolog, de ha mindenki kiválasztja a saját kedvencét, akkor abból akkora katyvasz lesz...senki nem tudja majd a másik kódját rendesen értelmezni.
Az nem baj, ha egy nyelv fejlődik, de kérdés, hogy hova és kérdés, hogy egyáltalán fejlődésnek lehet-e ezt nevezni. Nézzük a pipe operátort. Ez arra való, hogy - nomen est omen - csöveket kössünk össze vele. Namármost egy változó, vagy egy függvény minden csak nem cső. Eddiglen volt a nyelvnek egy logikája, hogy a függvényeknek paramétert adunk át és most ezt rúgjuk fel, hogy ad-hoc rá lehet irányítani valamit. (Tényleg, mit csinál ez egy több bemenetes fügvénynél? Errort dob? Vagy mit csinál, ha objektumot irányítok egy függvényre? Vagy egy változót egy objektumra? Függvényt egy objektumra?) Hovatovább, az adott példa
let url = "%21" |> decodeURI;
még unintuitív is, amennyiben "csövesen" gondolkodunk, hiszen a cső egyfelé megy, azaz itt az ember úgy gondolná, hogy a decodeURI
cél és nincs tovább. Hiába van előtte egy értékadás; nem egyértelmű, hogy ez most mit akar csinálni; az url
egyenlő lesz "%21"
-el és ez megy tovább a decodeURI
felé, vagy pedig a "%21"
elmegy a decodeURI
felé és utána megy vissza. Persze lehet mondani, hogy RTFM, mert leírják, hogy az utóbbi...de ha valakinek - aki ezzel még nem találkozott - szembejön egy ilyen kód, akkor nem biztos, hogy hirtelen érteni fogja és nem is csoda, mert itt egy shell-like pipe-operationt látunk, nem shell-like viselkedéssel. Ugyanez a felállás shell-ben ugyanis elküldi a célnak a cső bemenetére aggatott adatot, a változóba nem kerül semmi; ha ezt akarjuk, akkor azt jelezni kell: subshellbe kell rakni a kifejezést. Persze itt is be lehet zárójelezni és akkor rögtön egyértelmű lesz, de most zárójelezzük szénné az összes értékadást?
Én azt látom, hogy a JS folyton össze-nem-illő nyelvi elemeket és paradigmákat hány össze, aminek már számtalanszor megittuk a levét.
- A hozzászóláshoz be kell jelentkezni
Én PHP4-gyel kezdtem (sikerült kiheverni), aztán kis JS, C, C++, majd alapkutatói karrierem alatt Python+OpenCL a GPU programozáshoz, illetve C++ CUDA.
A pipeline operátor több, egymás utáni függvényhívásnál lehet majd hasznos (megjegyzem, fentebb rosszul írtam, még csak stage-1 proposal állapotban van, szóval változhat és el is vethetik.) Nekem a pipeline-os szintaktika átláthatóbb az alábbi példán:
let uj_ertek = otodik_fv(negyedik_fv(harmadik_fv(masodik_fv(elso_fv(ertek)))));
let uj_ertek = ertek
|> elso_fv
|> masodik_fv
|> harmadik_fv
|> negyedik_fv
|> otodik_fv
Számomra logikus, hogy a sor végén a változó aktuális értéke nem a /dev/null
-ba megy, hanem az uj_ertek
változóba kerül.
Több paraméteres függvénynél meg kell adni, hogy melyik argumentuma legyen a pipeline-ból származó változó:
let person = { score: 25 };
let newScore = person.score
|> double
|> (_ => add(7, _))
|> (_ => boundScore(0, 100, _));
Bármilyen típusú változót használhatsz a pipeline-nál, amit normál esetben is használnál.
De egyébként teljesen megértem a szkepticizmusodat az újdonságokkal szemben, nemrég a Python közösségben is nagy port kavart az új értékadási operátor bevezetése, amellyel időnként kvázi egy sort lehet megspórolni, de sokak szerint az átláthatóságot csökkenti, meglátjuk.
- A hozzászóláshoz be kell jelentkezni
Azt áruld el nekem, hogy ha a függvényes verziót egy sorban írod fel, akkor a csövest miért nem úgy?
let uj_ertek = ertek |> elso_fv |> masodik_fv |> harmadik_fv |> negyedik_fv |> otodik_fv
Vagy ha a csövest több sorba írod, akkor a függvényest miért nem úgy?
let uj_ertek =
otodik_fv(
negyedik_fv(
harmadik_fv(
masodik_fv(
elso_fv(ertek)
)
)
)
)
;
Mert így persze, hogy átláthatóbb lesz a csöves szintaktika.
> Számomra logikus, hogy a sor végén a változó aktuális értéke nem a /dev/null-ba megy, hanem az uj_ertek változóba kerül.
Ez attól függ, hogy ki mit látott előbb: funkcionális nyelvet, vagy shellscriptet. (Egyébként shellscript esetén sem a /dev/null
-ba megy, hanem a stdout
-ra.)
> Több paraméteres függvénynél meg kell adni, hogy melyik argumentuma legyen a pipeline-ból származó változó:
Ezt a kódot még értelmezni sem bírom rendesen. Ez most ez akar lenni?
let person = { score: 25 };
let newScore =
boundScore(
0,
100,
add(
7,
double(person.score)
)
)
;
Mert, ha igen, akkor ez aztán jól meg lett csavarva; ez minden csak nem könnyen értelmezhető. Arról nem is beszélve, hogy nem csak gépelni kell hozzá többet, de zárójelezni is. (6:8) Nem tudom mi forog ilyenkor a JS újításaiért felelős emberek fejében; cél, hogy minél átláthatatlanabb legyen a nyelv?
- A hozzászóláshoz be kell jelentkezni
A lényeg nem azon van, hogy hány karakter kell hozzá, hanem hogy milyen sorrendben van leírva a kódban. Az egyik esetben ugyanaz a sorrend ahogyan a végrehajtás is történik, a másikban fordított. Egyébként ez a partial applicationnel lesz teljes, akkor (a fenti példában legalábbis) lambdákra sem lesz szükség.
- A hozzászóláshoz be kell jelentkezni
> A lényeg nem azon van, hogy hány karakter kell hozzá, hanem hogy milyen sorrendben van leírva a kódban.
A lényeg tényleg nem a karaktereken van (bár nem mindegy, mennyit kell gépelni), hanem az olvashatóságon.
> Az egyik esetben ugyanaz a sorrend ahogyan a végrehajtás is történik, a másikban fordított.
Kivéve, hogy a legelőször felírt művelet (változó értékadása) hajtódik végre legutoljára. Azaz a sorrend 2->N, 1. Igen, az a függvényesben is, de ott legalább a sorrend konzisztens: N->1.
> Egyébként ez a partial applicationnel lesz teljes, akkor (a fenti példában legalábbis) lambdákra sem lesz szükség.
Mi a cél? Az önobfuszkálás? Csak mert affelé halad...
- A hozzászóláshoz be kell jelentkezni
Tévedés, az értékadás egy utasítás, az értékadás jobb oldala egy kifejezés. Megint csak két eltérő dologról van szó.
Javaslom, hogy ismerkedj meg egy tisztán funkcionális nyelvvel, akkor gyorsan helyére fognak kerülni ezek a fogalmak (function composition, partial application, currying, pattern matching / destructuring, stb.). Sajnos a JS nem a legjobb funkcionális nyelv, pláne hogy multi paradigm, de 2020-ban megkerülhetetlen a funkcionális programozás ismerete ha JS-ben akarsz programozni.
- A hozzászóláshoz be kell jelentkezni
> Tévedés, az értékadás egy utasítás, az értékadás jobb oldala egy kifejezés. Megint csak két eltérő dologról van szó.
var kecske = (x = y = do_something(65, 02)) | (z = do_something_else(kecske));
Az értékadás maga is egy kifejezés. Ezt a kódot hogy írod át csövesbe? Úgy, hogy egy utasítás maradjon.
> Javaslom, hogy ismerkedj meg egy tisztán funkcionális nyelvvel, akkor gyorsan helyére fognak kerülni ezek a fogalmak (function composition, partial application, currying, pattern matching / destructuring, stb.).
Egyszer lehet, hogy sor kerül rá, de most nem prioritás.
> Sajnos a JS nem a legjobb funkcionális nyelv, pláne hogy multi paradigm, de 2020-ban megkerülhetetlen a funkcionális programozás ismerete ha JS-ben akarsz programozni.
Na, pont ezért egy raklap alsógatya a JS. Mint mondtam, összehányt különféle paradigmákból egy raklap önkényesen kiválogatott nyelvi elemet és megközelítést, a programozó meg ihatja a levét. A JS nem a legjobb funkcionális nyelv, nem a legjobb OOP, nem a legjobb procedurális...kb. mindegyikből a hátrányokat sikerült összelapátolni. (Majdnemhogy.) Amúgy ez a 2020-azás nem korai még egy kicsit? 5 napja van még csak 2020, a pszeudoprogresszív mindenit neki.
- A hozzászóláshoz be kell jelentkezni
Ezt a kódot hogy írod át csövesbe?
Sehogy, mert ezt nem kell átírni. A pipe eszköz egy feladatra, többnyire egy érték több lépésen át történő transzformációjára. A fenti kódod nem ilyen.
- A hozzászóláshoz be kell jelentkezni
Nem azon volt a hangsúly, hanem azon, hogy kötött műveleti sorrendre, mint előnyre ne hivatkozzunk már, főleg, ha az ráadásul nem is úgy van, ahogy azt a Móriczka elképzeli.
- A hozzászóláshoz be kell jelentkezni
Aha, fasza. Adsz egy kódot, amit felesleges pipe-osítani, majd ezzel igazolod, hogy faszság az egész.
- A hozzászóláshoz be kell jelentkezni
Nem! Én nem ezt mondtam, hogy fasság az egész! Ne adj szavakat a számba! Én azt mondtam, hogy a műveleti sorrend, mint a pipeline-s megoldás mellett szóló érv a procedurálissal szemben, az invalid. Ennyit és nem többet. A többit te láttad bele, mert már megint könnyebb arra reagálni, amit hinni akarsz, hogy mondtam, mint arra, amit mondtam. No comment.
- A hozzászóláshoz be kell jelentkezni
De nem invalid. Kijelented, bizonyítékod nincs, a példakódod pedig nem passzol a témához.
- A hozzászóláshoz be kell jelentkezni
Hogy mi van...? Az eredeti példakódot nem is én írtam és ez arra is vonatkozott... Az értékadás maga is lehet kifejezés (ezen mit bizonyítsak?), a pipeline-os megközelítésnél meg az értékadás marad utoljára, holott az van legelől (és ezen?).
- A hozzászóláshoz be kell jelentkezni
Ez attól függ, hogy ki mit látott előbb: funkcionális nyelvet, vagy shellscriptet
Javíts ki, ha tévedek, de funkcionális nyelvekben azért szokott lenni pipe operátor, vagy annak híján valami függvény, amivel megteheted ugyanazt. A pipe objektven jobb, hiszen végrehajtás sorrendjében írod le az elvégzendő műveleteket, és függetlenül attól, hogy egy vagy több sorba írod, áttekinthetőbb lesz.
- A hozzászóláshoz be kell jelentkezni
Kész... :))) Hallod, itt van egy poszttal feljebb kivesézve, hogy ez nem igaz, mert az értékadás fut le a legvégén, holott az van a legelején, így aztán a valós sorrend 2->N,1, míg a procedurális megközelítésnél a nestingből logikusan következő - és nem fragmentált - N->1. Tényleg nem olvasod el, amit írok?
- A hozzászóláshoz be kell jelentkezni
De olvastam, és értem mit mondasz, sőt, igazad is van bizonyos szempontból. De két dolgot mosol össze, az értékadást, és a pipe-olást, utóbbi egy önálló műveletlánc, aminek az értékadás nem a része. Még ha az is lenne, nem számít, mert apróság főleg egy hosszabb lánchoz képest, aminek az áttekinthetőségén nem ront.
- A hozzászóláshoz be kell jelentkezni
Ennyi erővel minden egyes függvényhívás egy önálló műveletlánc. Egyébként nem én mosom össze, hanem az emberi agy. Az egyiknél elindul jobbról balra (bentről kifele) és végigmegy, a másiknál meg balról jobbra, majd ugorhat vissza.
- A hozzászóláshoz be kell jelentkezni
Azért formáztam így, hogy minél inkább "valódi" kódból kivett példának tűnjön. A pipeline operátornál több (mondjuk >= 3) elem esetén már külön sorba raknám őket, úgy áttekinthetőbb számomra.
A pipeline-nál el tudnék képzelni olyan szintaktikát is, hogy a sor végére lehetne rakni a változót, ahova a végeredmény kerüljön. De gondolom nem akarták ennyire megkavarni a szintaktikát.
- A hozzászóláshoz be kell jelentkezni
Ok, de be lehet tördelni a procedurálisat is, akkor az is áttekinthetőbb.
Lehetne úgy is, mindenesetre egy non-shell nyelvben egyértelműbb lenne; ha függvénybe lehet pipe-olni, akkor változóba is. Annak legalább garantáltan egy "bemenete" van. Szerintem csak nem igazán tudják a JS háza táján, hogy mit csinálnak.
- A hozzászóláshoz be kell jelentkezni
Ezért jók a transpilerek. Alapvetően nem szeretem őket ezért sima (+modern ;)) node-nál nem is használnám de böngészőben megértem a használatát.
Igazad van de JavaScript kontextusban vagyunk, erre vonatkozóan írtam... és persze igazad van, biztos találsz olyan szabályt JS világban ahol nem így van, de próbálok nem árral szemben úszni és követem a nagyokat (airbnb, google, stb). Azért is jók ezek a szabályok mert szól ha ilyen hibát követsz el (most kiírna hogy nem fog lefutni - unreachable code).
A te bajod hogy nem adaptálódsz a használt technológiához, azt erőlteted bele amit már ismersz (meg persze a nyelvtervezés vagy nem tervezés) - az informatika nem így működik. Jogos hogy nem tökéletes a JS (nagyon nem az), de minden nyelvben találsz hülyeségeket.
- A hozzászóláshoz be kell jelentkezni
> Ezért jók a transpilerek. Alapvetően nem szeretem őket ezért sima (+modern ;)) node-nál nem is használnám de böngészőben megértem a használatát.
Nem mertem kipróbálni; csak abban a kódban bízok, aminek a működését értem és tudom hol lehet benne a hiba, ha valami megborul. Ezért kerülöm a JS keretrendszereket is. Egy transpiler által generált kódot kidebuggolni biztos nagyon vicces lehet.
> de próbálok nem árral szemben úszni és követem a nagyokat (airbnb, google, stb)
Én sem direkt úsztam szemben az árral; csak eszembe se jutott, hogy egy többsoros utasításnál ő lezárja helyettem az utasítást az első sorban. :/
> Azért is jók ezek a szabályok mert szól ha ilyen hibát követsz el (most kiírna hogy nem fog lefutni - unreachable code).
A BaT által citált lintert leszámítva eddig semmi nem reklamált érte.
> A te bajod hogy nem adaptálódsz a használt technológiához, azt erőlteted bele amit már ismersz (meg persze a nyelvtervezés vagy nem tervezés) - az informatika nem így működik.
Nem én...a böngészők! Nem csak a latest Chrome van, az informatika nem így működik. :P Szerinted miért szívnak ezer helyen legacy dolgokkal? (Másik ezer helyen meg a nagyon modern dolgokkal, mert manapság sajnos sokszor az innováció után rosszabb lesz, mint előtte. :( )
> Jogos hogy nem tökéletes a JS (nagyon nem az), de minden nyelvben találsz hülyeségeket.
Na de ennyit? :)
Több, mint 30 éve ülök gép előtt, majd ugyanennyi éve kezdtem a programozást is, sok nyelvet láttam, de ennyi szamárságot, inkonzisztenciát és logikai bukfencet egyetlen nyelvben sem láttam, mint a JS-ben. Nem még PHP-ban sem, pedig az nagy szó.
- A hozzászóláshoz be kell jelentkezni
Egy transpiler által generált kódot kidebuggolni biztos nagyon vicces lehet - Ezért generálnak egy mapot is debug módban vagy amikor bekapcsolod, de ettől meg lehet szívás (pl nem tudod rávenni Chrome-ot hogy figyelembe vegye).
ő lezárja helyettem az utasítást az első sorban - ilyen ez a pop szakma, hogy a jövőben ne forduljon elő, MDN. :D
Szívok legacy dolgokkal is, de szerencsére van akarás a javítására (persze van akinek ez se tetszik :/). Elég szomorú olyan JS kódot nézni ami úgy néz ki mint egy 20 éves java/c# borzadály...
Na de ennyit? - ezért utáltam a JS-t úgy hogy sose láttam, eleget hallottam róla. De azzal, hogy van egy elég modern JS (es6+) és ebben kezdtem el fejleszteni megszerettem. 5-10 évvel korábban lehet örökre megutáltam volna.
Rakj fel egy VSCode-ot és az ESLint plugint (lehet nem is kell?). Nekem szabály nélküli projektben aláhúzza az ilyet. - szerk: oké, BaT is ezt írta. :D
- A hozzászóláshoz be kell jelentkezni
> Ezért generálnak egy mapot is debug módban vagy amikor bekapcsolod, de ettől meg lehet szívás (pl nem tudod rávenni Chrome-ot hogy figyelembe vegye).
Majd, ha nagyon nincs mivel szívni, lehet kipróbálok egy ilyet. :P
> ilyen ez a pop szakma, hogy a jövőben ne forduljon elő, MDN. :D
Ez már eső után köpönyeg... :P Az összes ilyen baromságát meg nem ismerheti az ember a nyelvnek, biztos lesz még itt bazmeg. :/
> Szívok legacy dolgokkal is, de szerencsére van akarás a javítására (persze van akinek ez se tetszik :/). Elég szomorú olyan JS kódot nézni ami úgy néz ki mint egy 20 éves java/c# borzadály...
Java-t/C#-ot még manapság is borzadály nézni. :) Előbbinek a végeredményét futtatni is...
> ezért utáltam a JS-t úgy hogy sose láttam, eleget hallottam róla. De azzal, hogy van egy elég modern JS (es6+) és ebben kezdtem el fejleszteni megszerettem. 5-10 évvel korábban lehet örökre megutáltam volna.
Én 16 éve kínlódok vele...képzelheted én hogy utálom. :D
Sz*rk: VSCode...NO WAY. Nem tudom van-e egyáltalán UNIX-ra, de ha van se kell.
- A hozzászóláshoz be kell jelentkezni
VS Code megy több platformon is, de ott van a https://github.com/VSCodium/vscodium is, amiből kiszedték az MS telemetriáját. Illetve Sublime Text-hez is van ESLint plugin, meg még számos szerkesztőhöz.
- A hozzászóláshoz be kell jelentkezni
> VS Code megy több platformon is, de ott van a https://github.com/VSCodium/vscodium is, amiből kiszedték az MS telemetriáját.
Még szerencse. Akkor most már csak át kell írni valami normális nyelvre, hogy ne falja fel a gépet. :P Thx no, maradok a saját editoromnál.
> Illetve Sublime Text-hez is van ESLint plugin, meg még számos szerkesztőhöz.
A Sublime már inkább érdekel, de azért még megnézem, hátha van az én szerkesztőmhöz is; thx.
- A hozzászóláshoz be kell jelentkezni
Milyen szerkesztőt használsz, ha megkérdezhetem? Egyébként beállíthatod úgy is, hogy egy precommit hook-ban fusson le az ESLint ellenőrzés, ha az jobban kézre áll. Így nem enged olyan kódot kommitolni, amiben problémás részek vannak (állítható természetesen a hibaszint).
- A hozzászóláshoz be kell jelentkezni
A TDE által szállíott Kate-et. Plugint nem találtam, de lehet ezt használni CLI-ből is. Commit itt nincsen.
- A hozzászóláshoz be kell jelentkezni
A példában 3 feltétel volt, de mi van, ha 30 van?
Azt eleve nem egy return után írod, hanem mondjuk egy tömbbe, és tomb.includes(valami)-t használsz.
- A hozzászóláshoz be kell jelentkezni
Nem. Ezt is leírtam már, hogy nem biztos, hogy egyszerű lista lesz, lehet, hogy komplexebb kapcsolatok lesznek. Nem is egyszer. Elolvastad te egyáltalán amiket írtam?
- A hozzászóláshoz be kell jelentkezni
Ne szívd fel magad ennyire, tényleg leírtad, elsiklottam felette.
Ettől függetlenül tartom magam ahhoz amire ki akartam lyukadni: Jó elszeparálni az adatot és a kódot ami azt kezeli. Mert így az adatok mint konfiguráció könnyebben kezelhető a függvényed mint kód jobban unit tesztelhető. És ez úgy se nehéz, ha komlpex feltételeid vannak, egyszerűen nem string egyezőséget vizsgálsz a tömb elemein, hanem mást. Mondjuk regexet (is) és / vagy lamdbákat hívsz. Nem ördögtől való, így működik az array filter is.
És persze mondhatod, hogy ez felesleges bonyolítás, de miért is? Egy URL listát, vagy feltétel listát előbb találsz meg egy config fájlban, mint egy script közepén. Így az a lista jobban kezelhető, a kódod pedig unit tesztelhető. Nyilván erre semmi szükség ha csak egy röpke scriptet dobsz össze magadnak.
A felvetett teljesítménybeli aggályok pedig feleslegesek amíg nem keletkezik ebből tényleges bottleneck, főleg úgy, hogy feláldoznád vele a karbantarthatóságot és tesztelhetőséget.
- A hozzászóláshoz be kell jelentkezni
> Ne szívd fel magad ennyire, tényleg leírtad, elsiklottam felette.
Na jó, de ötször? :)
> Ettől függetlenül tartom magam ahhoz amire ki akartam lyukadni: Jó elszeparálni az adatot és a kódot ami azt kezeli. Mert így az adatok mint konfiguráció könnyebben kezelhető a függvényed mint kód jobban unit tesztelhető. És ez úgy se nehéz, ha komlpex feltételeid vannak, egyszerűen nem string egyezőséget vizsgálsz a tömb elemein, hanem mást. Mondjuk regexet (is) és / vagy lamdbákat hívsz. Nem ördögtől való, így működik az array filter is.
> És persze mondhatod, hogy ez felesleges bonyolítás, de miért is? Egy URL listát, vagy feltétel listát előbb találsz meg egy config fájlban, mint egy script közepén. Így az a lista jobban kezelhető, a kódod pedig unit tesztelhető. Nyilván erre semmi szükség ha csak egy röpke scriptet dobsz össze magadnak.
Aha és a konfigfájlban található adatsémákhoz hoz mindjárt találjak ki codebuildert is, ha komolyabb kapcsolatokat akarok felépíteni, ugye? Itt egy célfeladatról beszélünk. Nem építünk hozzá általános eszközt.
> A felvetett teljesítménybeli aggályok pedig feleslegesek amíg nem keletkezik ebből tényleges bottleneck, főleg úgy, hogy feláldoznád vele a karbantarthatóságot és tesztelhetőséget.
Ha nem túl sebességkritikus, akkor még csak-csak le lehet írni a regex okozta overheadet, de ami azt illeti nekem egy regex sokkal kevésbé átláthatóbb, mint egy logikai kapcsolatrendszer.
- A hozzászóláshoz be kell jelentkezni
Miért kéne külön codebuilder? Lehet a config kód, a lényeg a szeparáció :)
- A hozzászóláshoz be kell jelentkezni
Ööö...láttad te a nyitó kódot? A logikai szerkezet tkp. el van szeparálva. Annyi van előtte, hogy a beérkező stringből csak a domainnév marad meg, ami kb. 3 sor volt. Most ezt a 3 sort hagyjam meg itt és az egy darab returnt meg tegyem külön függvénybe? El szoktam szeparálni amit el kell, de ebben az esetben ez már overengineering.
- A hozzászóláshoz be kell jelentkezni
Mondom, kis scriptnél nyilván nem feltétlenül játszik ez.
De gondoljuk tovább: Nem tudod elképzelni, hogy a scripted egyszer csak bővül mondjuk úgy, hogy a domainből nem fixen az utolsó két szegmenst hagyod meg, hanem végződéstől függően potenciálisan többet (mondjuk támogatandó az xxx.co.uk és hasonló címeket)? Rögtön nem három sor lesz az :)
- A hozzászóláshoz be kell jelentkezni
Ebben az esetben, amivel most dolgom van, nem lesz ilyen. Mondtam: ez célfeladathoz céleszköz. Amit el kell szeparálni, azt el szoktam én is.
- A hozzászóláshoz be kell jelentkezni
Az a baj, hogy én pl. InDesignt programozok JS-ből, ami írd és mondd, 2020-ban ES3-at ért csak!
- A hozzászóláshoz be kell jelentkezni
Nagyon szomorú, hogy ilyet ad az Adobe. :/
- A hozzászóláshoz be kell jelentkezni
Nem feltétlen. Ipari környezetben sokszor vannak baromi régi böngészők; fentebbi válaszomban mondtam egy (saját tapasztalati) példát.
Sz*rk: Ez kissé félreérthető lett; nem konkrétan az InDesignre gondoltam, hanem bármilyen JS programmable szoftverre, ami régi szabványokat követ.
- A hozzászóláshoz be kell jelentkezni