Szia!

A PHP egy kicsit "hülyén" van összerakva több tekintetben is, ide tartozik a kisbetű-nagybetű érzékenység is, ami hol így, hol úgy működik.
Többekközt a konstansok is érzékenyek a kis- és nagybetűkre, a $_POST pedig ezek közé tartozik, így erre mindenképpen oda kell figyelni.
Ezért nem szeretem, ha egy nyelvben nem kötelező az előzetes deklaráció: Ahelyett, hogy közölné, hogy rossz változónevet fogdosok, úgy tesz, mintha minden a terv szerint menne, aztán már csak a nem megfelelő viselkedés alapján kezdhetek el gyanakodni, hogy valami nem kerek - és persze olvashatom át és/vagy debugolhatom az egészet, hogy kiderüljön, hol írtam el valamit...

Ha szabad javasolnom, más, nem kísérleti jellegű kódokban szedd külön a megjelenítést (kb. print/echo és html), az adatbázis-kezelést és az ún. "üzleti logikát", mert nagyon meg tudod magad szivatni, ha arra szoksz rá, hogy egy helyen összekutyuld a különböző koncepciókat és feladatokat.

Továbbá érdemes a string literálokat (pl. 'veznev') konstansokban centralizálni, elkerülendő, hogy egy typo, vagy egy esetleges jövőbeni módosítás véletlenül hiányos kivitelezése fejvakarós problémákat okozzon. Ha van egy konstansod, akkor csak egy helyen kell módosítani az értéket, hogy mindenhol az új legyen használva, és a változtatás még véletlenül se maradjon ki sehol.

A legfontosabb tanácsom azonban az volna, hogy ezeket a tutorialokat ne másold le betű szerint, mert gyakran borzasztó hibákra tanítanak.
PHP körökben - legalábbis ami a hobbista közösséget illeti - sajnos kiemelten jellemző, hogy olyanok próbálják oktatni, akik maguk sem tudják teljes mértékben, hogy mit csinálnak. Ennek oka, hogy a nyelvvel minden hülyesége ellenére gyorsan érhető el relatíve látványos eredmény, ami gyakran túlzott magabiztosságot hoz magával. Az eredmény többnyire durva gányolás. Az ember viszont a látszat alapján azt hiheti, mindent lényegeset tud már, amit lehet, és megpróbálja tanítani - azt, amit rosszul tud. Óvatosan! Mindig gondold át, vajon lehetne-e egy látott kódkupac olvashatóbb, szervezettebb, flexibilisebb.

Ha bármi kérdésed van, keress bátran, akár itt, akár privátban!

Köszönöm a tanácsokat, Én csak "elemi" gyakorlásként kíváncsiságból nézegetem/próbálgatom a programozást.

Amúgy mi a különbség a két string között: pl. 'veznev' és `veznev`?

Az aposztróf PHP-ban és SQL-ben is használatos string delimiter, a "backtick" SQL-ben használatos a foglalt kulcsszavak és speciális karakterek escape-elésére. Ilyen esetben arra jó, hogy ne eredményezzen hibát, ha pl. egy mező neve where, from, stb.

A programozás egyébként jó móka. Ha tetszik, én csak bátorítani tudlak, hogy csináld

Köszönöm!
Érdekel, de nekem "kicsit" magas..

Valahol el kell kezdeni Senki sem úgy kezdi, hogy rögtön a kisujjából kirázza a dolgot; nehogy azért add fel, mert elsőre nem tűnik minden szögegyszerűnek Belejössz.

A Windows, mint olyan többnyire nem különbözteti meg, de egyébként igen, szigorúan számít. Főleg programnyelvnél. Én azt javaslom, hogy ne csak példakódokat nézegess és próbálgass, hanem tanulmányozd az adott programnyelv referenciáját, szintaxisát.
Tananyagok is elérhetők a neten, illetve könyvek is. Pl itt is találsz egy PHP leírást.

Köszi a linket, tanulmányozni fogom.

Szia!
A script nyelvek előnye, hogy nem kell deklarálni a változókat és ezáltal futási időben is dinamikusan összerakható egy változóra hivatkozás vagy egy függvényhívás. A .NET C# pl. script nyelv, de megkövetel előzetes deklarációt, így fordítási időben már kijöhetnek az elírások.
Amúgy mindennel egyetértek amit írsz, csak ezt az egy kijelentést nem tudtam hová tenni az előzetes deklarációval, de persze csak azt állítod, hogy nem szereted ami szíved joga.
Vannak nagyon jó editorok, amiknek remekül működik az auto completion, ami nagyságrendekkel csökkenti az elgépelés lehetőségét. Figyelmedbe ajánlom a brackets-et, online preview-al, de van jópár nodejs-re és cef-re épülő modern editor, amivel érdemes megismerkedni (atom.io) és azzal megtanulni a nyelvet.
A kezdőknek fontos a sikerélmény (később is amúgy) és tény, hogy egyszerűbb feladatokat gyorsabb és "átláthatóbb" katyvaszként megírni, mint több rétegben külön üzleti logikával.
Sajnos azt tapasztalom "senior" programozóknál is elmarad ez a szemlélet és nem tudod meggyőzni őket, hogy másképp csinálják. Persze lehet ez a megoldás, hogy már a kezdőket erre szokatni, de mint írtam az meg nem olyan produktív.

A C# nem script nyelv.

A C# nem szkriptnyelv ám

Az előzetes deklarációnak, mint ahogyan említettem is, megvan az az előnye, hogy gyorsan kiderül, ha véletlenül elgépelsz egy azonosítót. Ha ez a feature nincs meg, annak gyakran fejvakarás a vége az első hibázásnál. A mérleg másik oldalán mindössze minimális kényelem lakik, így a risk-reward-ratio nem az igazi . Az auto-completion jogos felvetés, de kezdőkre, lelkes laikusokra általában nem jellemző, hogy egy komplexebb IDE-t használjanak, a Notepad++ meg etéren szinte teljesen használhatatlan. Az oldal látogatói közül bizonyára sokan apokaliptikus pánikba esnének pl. egy Eclipse láttán, és állítom mindezt bármiféle rosszindulat nélkül; én sem lennék magabiztosabb egy Space Shuttle pilótafülkéjében.

Igazán jó PHP IDE-t egyébként eleddig még nemigen láttam, csak amolyan "hááááá... jó-jó, legyen" jellegűt. Egyetlen kivétel ugrik csak be, a Zend Studio, ami elég jónak tűnt, de sajna fizetős. (Framework dettó)

Kezdőként bizonyos esetekben valóban célravezetőbb a katyvasz, ám ha a tutorial úgy vezeti elő, mintha az adott katyvasz lenne az üzemszerű, a "normális", akkor ott nagy a baj. Hiszen honnan is tudná az a szegény, a nyelvvel épp ismerkedő lélek, hogy csak a példa leegyszerűsítése kedvéért katyvasz az a katyvasz? Nyilván nem tudja, és begyakorolt mozdulatokkal szivatja meg saját magát, amikor valami komolyabbat próbál majd összehozni saját kútfőből - elvégre senki nem szólt, hogy lehet ezt jobban is. Azt persze én sem javasolnám, hogy komplex enterprise megoldásokkal bombázza valaki az utat keresőket, de a kód szervezésének mikéntjére talán érdemes őket már a tanulás korai szakaszaiban rávezetni. Mintha fiókokba pakolnék: Nem teszem a cukrot és a lisztet egy helyre a zoknikkal A többit, a bonyolultabb húzásokat meg lehet szépen, fokozatosan bevezetni. Persze, mivel nem vagyok oktató, így akár tévedhetek is a megközelítést illetően, abban viszont biztos vagyok, hogy a nyilvánvaló tákolás elhallgatása a kezdők elől nem feltétlenül egészséges.

Senioroknál nagyon el tudok keseredni, amikor gányolást látok, hiszen nekik épp azért járna a "senior" cím, mert önállóan, gyorsan, taknyolás nélkül tudnak jó megoldásokkal előrukkolni, és mindehhez iránymutatást is tudnak nyújtani a kevésbé tapasztaltaknak - a mesekönyvekben
Szerencsére azért tehetséges kollégából is sokkal találkozom, velük mindig öröm dolgozni.

Akkor úgy mondom a .NET CLR egy script nyelv, a C# pedig ugyan típusos, meg előfordít, de nem natív kódot fordít. Érdemes ránézni egy C# REPL -re, vagy utánanézni a Common Langauge Runtime-nak, persze csak ha érdekel a téma.
Azért ajánlottam a brackets-et és az atom editort, mert ezek nagyon látványos és modern editorok, akár kezdőknek is és persze opensource. Ha fizetős, akkor a PHPStorm-ot ajánlom, ugyan én magam nem dolgoztam vele, de a csehek igen jó IDE-ket raktak össze.
Én különválasztanám azt aki meg akarja tanulni valamelyik nyelvet, pl a PHP-t és azt aki meg akar oldani bizonyos "webes" feladatot és a PHP-t választja. Aki meg akarja tanulni a PHP-t, de már van programozói ismerete, akkor ő igényelni fogja a többrétegű programkészítést, mert ismeri annak az előnyeit, aki pedig csak formokat akar feldolgozni, annak nincsenek ilyen igényei.

Ne is mondd... El vagyok keseredve, amikor senior programozó volt munkatársaim kreálmányaiba bele kell nyúljak néha, egy teljes rémálom, egy csőd. Ilyenkor sajnos nagyot csalódott vagyok bennük.

Nem firtatom, hogy mindig időhiány van, és termelni kell, haladni és vágtatni, de ezt mégsem tudom mentségként elkönyvelni arra, hogy kisebb nagyobb szoftverek pl. részben vagy egészben mellőzzék a hibakezelés bármiféle fajtáját. Az ilyenektől a szőr áll a hátamon. Természetesen az említett helyzet együtt szokott járni néha azzal, hogy a szoftver egyes részei nem működnek, lefagynak, összekutyulnak adatokat, úm. meghamisítva véletlenül az eredményeket. Teszteletlenség és kókányolás. Nem a barátom.

Nyilván előfordul, hogy én is összecsapok valamit, de aztán akár órákat vagy napokat is képes vagyok eltölteni azzal, hogy letisztázzam. A magam érdekében.

No igen, ismerős a szitu...
Rángógörcsöt tud kapni az arcom, amikor meglátok egy hetvenháromszorosan egymásba ágyazott blokktengert egy nyolcezer soros metódusban, ráadásul mindezt egy seniornak kikiáltott kolléga "tollából". Esküszöm, legközelebb egészségügyi okokra hivatkozva veszélyességi pótlékot fogok kérni az ilyesmire

A .NET CLR nem egy programozási nyelv, így nem lehet script nyelv sem.
Az való igaz, hogy első körben nem kapsz natív kódot, viszont az első futtatásnál, vagy installnál ráfut az ngen és máris natív kóddá alakul. Ez a natív kód meg bekerül a natív cachebe és a továbbiakban ő fog futni. Ez a portabilitás miatt van. Így műxik a .NET.

OK, kihátrálok az állításomból, miszerint a C# script nyelv, mikor a CLR-es részt leírtam már én is éreztem, hogy nem tudom megvédeni, mert a CLR mint írtad te is nem programnyelv.
Mindenesetre fenntartom, hogy nem natív kódot fordít és interpreter kell a futtatásához valamint scriptre jellemző futást valósít meg, mikor futási időben forráskódot tudsz fordítani/futtatni.

sajnos én néha a saját régebbi kódjaimban is találkozok olyan megoldásokkal, amihez ma már nem adnám a nevem. A programozásban is mint szerintem mindenben az önbizalom fontos tényező. Lehet pont a katyvasz mintakódokból következik, de voltak kódok amiket elkövettem évekkel ezelőtt és emlékszem akkor teljesen elégedett voltam én is és a környezet is, pedig ma elnézve könny szökik a szemembe és nem a meghatottságtól.
Én azt látom, hogy nincs kontroll a munkaadók részéről, teljesen ugyanolyan kategóriába esel évek múlva is mint az a kollégád aki arcán az értetlenség ül ki mikor az üzleti logika különválasztása a megjelenítéstől és annak megvalósításairól beszélsz neki. Nekem mindig egy MPFC poén jut eszembe "Pearls for Swine Production Presents".
Annó sok siralmas kódot örököltem meg, amikről sokáig azt feltételeztem, hogy tudatosan lettek úgy megírva, ezért évekig körbeprogramoztam őket. Majd később világosodtam meg, hogy azok csak úgy sikerültek, nem tudatos szervezés következménye. De én kívülről, messziről érkeztem a programozás világába.

Igazából részletkérdés, hogy a compiler milyen outputot állít elő, t.i. minden további nélkül tekinthető ugyanúgy cross-compilationnek, mint amikor pl. Linux alól fordítasz Win32 natív alkalmazást: A beforgatáshoz használt rendszeren nem natív, csak virtuálisan futtatható, de pusztán emiatt még nem lesz szkript. A menedzselt nyelvekre nem nagyon lehet mást mondani, mint amik: öszvérek. Persze ez nem negatívum.

Ezen a témán szerény véleményem szerint felesleges is rágódni, tekintve hogy az interpreted és compiled nyelvek egyre inkább összemosódnak. Pl. ma már a JavaScript is JIT-es motoron fut.

Szegény Karival jól kib___tunk, hogy szétoffoljuk a threadet

Erre mondják, hogy jó pap holtig tanul.

Van egy projekt, amire a mai napig örömmel gondolok vissza, mert sikerült úgy eltalálni mindenkivel a dolgokat, hogy rendkívül gördülékenyen tudtunk dolgozni. Ugyanakkor tökugyanazt a kódot ma már nagyon máshogyan szervezném, mert az anemic domain modellel azért sikerült rútul mellélőni Nem vállalhatatlan, sőt, azokhoz a megoldásokhoz képest, amiket az elmúlt fél évben láttam, kiváló, de azzal, hogy egy vaskos antipatternre épül az alkalmazás, nem profi.

Ezzel szerintem mindenki így van. Nincs olyan kódom amit egy idő után már nem másképp írtam volna meg.

Pontosan. De ennek örülni kell, ebből látszik, hogy az ember mindig fejlődik valamennyit. Tizenhét-nyolc év után persze már nem olyan látványos a tempó, de azért még ennyi idő elmúltával is tanul néha az ember valami újat, jobbat. Ha nem így lenne, az lenne a gond

Csak halkan... Bővebben: Link

Valaki tudja hogy kell normálisan sugárkorrekciózni? Miért megy bele az anyagba a kés ott ahol nem is szabadna sugarat korrekciózni mert az párhuzamos ahossztengelyekkel? Minden jól van megadva a kés állás is meg a korrekció iránya is hogy jobbról vagy balról tegye de akárhányszor csináltam mindig a hót ellenkezőjét csinálja a gép belevág az anyagba a hosszak mentén mikor ott nem is térhetne el az eredeti pályától.

Sziasztok!
Van egy eszközöm ami USB-n keresztül csatlakozik a számítógéphez. Ez az eszköz egy kiküldött parancsra válaszol. A kérdésem az, hogy hogyan tudom C-ben leprogramozni, hogy egy megadott COM porton kiküldjem a parancsot az eszköz felé, majd a kapott választ eltároljam egy változóban.
Az egyszerűség kedvéért egy számot küldök ki parancsként (pl. 4) mire az eszköz (pl. egy Arduino) a 4. analóg lábán mért feszültség értékét küldi be.
Hogyan tudok adatot beolvasni C-ben COM portról?
Az rendben, hogy billentyűzetről a scanf() paranccsal tudok beolvasni, monitorra pedig a printf() paranccsal tudok kiíratni, de COM portnál ez hogyan működik?
Eddig semmit nem találtam a neten róla, de biztos, hogy rosszul keresem.
Előre is köszönöm!

Szia!
Gondolom Windows alatt kérdéses.
CreateFile hívással nyisd meg a virtuális COM portot, utána tudod írni és olvasni.


Ha nagyobb a port száma, mint 9, akkor így nézzen ki a neve: "\\\\.\\COM10"

A soros portnál sok beállítási és kezelési lehetőség van. Ötletadónak:
ttytest.c
makefile

Köszönöm mindkettőtök válaszát. Tanulmányozom, értelmezem a látottakat. Ez nekem teljesen új terület, szóval jól el leszek vele.
Ha megakadtam akkor még garantáltan jelentkezem.

Sziasztok! Nem tudom jó helyen érdeklődök-e.Azt szeretném megkérdezni hogy hogyan kell elvégezni az "uncoming" parancsot hogy kijelöljek valamit, ami előtt ez van //#
Mit kell kitöröljek? Köszi előre is.

Bocsi.Uncomment parancsot akartam írni.Egy chip átprogramozásáról van szó.

Igen nagy valószinűséggel a "//"-t kell törölni, mert sok nyelvben az a comment sor jelzése.
A "#" sor elején viszont jelentéssel szokott birni...

A // és a # is kommentet jelöl egyes programnyelvekben.