Hei!
Olisi jonkin verran kysymyksiä vähän sieltä sun täältä.
1. Opiskelen tällä hetkellä (kirjasta) php5:tä, siellä on pari lukua omistettu olio-ohjelmoinnille. Mietin näiden lukujen jälkeen, jotta mihinkähän näitä mahdetaan tarvita, siis minkä typpisessä projektissa tarvinee olio-ohjelmointia, luokkia yms?
2.Voiko sql-kyselyitä yhdistää samaan kyselyyn? Eli siis pystynkö yhdistämään samaan kyselyyn vaikka updaten,selectin,insertin ja deleten?
$Kysely = $Yhteys->prepare("Tähän samaan kyselyyn select, ja jotain muita kyselyitä");Voiko näitä select-kyselyiyä yhdistää useampia yhteen kyselyyn, miten tämän toteutu käytännössä tapahtuisi, kun en ainakaan äkkiseltään keksi tapaa jolla kaksi select-kyselyä voitaisiin yhdistää yhdeksi.
3. Sitten tämä iän ikuinen asia, joka häirihtee mua aina sillon tällöin, htmlspecialchars(). Asia on nimittäin sillai, jotta mää haluan itselle selkeän kuvan asiasta. Eli pitääkö seuraavat väittämät paikkansa:
Mulla on muuttuja x, johon haen $_POST[]:lla tiedon.
- Tallennan sen tiedon tietokantaan pdo:lla, ja laita muuttujan x, execute():n sisään, minun ei tarvitse käyttää htmlspecialchars()-functiota.
- Käytän muuttujan sisältöä ehtona(WHERE) sql-lauseessa, minä en saa käyttää ko. funktiota.
- Tulostan muuttujan sisällön selain ikkunnaan, minun pitää käyttää ko. funktiota.
- Käsittelen muutujan sisältöä php:llä, jonka jälkeen tallenna tiedon tietokantaan, ja sitten vielä tulostan tiedon selaimelle, minun tulee käyttää htmlspecialchars()-funktiota vasta sen jälkeen, kun olen tehnyt sql-kyselyn.
Eihän sinne ole tarkoituskaan laittaa html-muotoiluja vaan nimenomaan htmlspecialcharsin ansiosta teksti: "kun a<b ja b>c, on ... " näyttää järkevältä.
1. Oikein käytettynä olio-ohjelmointi usein selventää koodin rakennetta. Varsinaisesti sitä ei tarvita mihinkään.
2. SQL-kyselyt suoritetaan PHP:ssä yksitellen, eikä niiden yhdistämisessä olisi mitään järkeäkään.
3. Selvitä kunnolla, mitä htmlspecialchars tekee, niin toivottavasti ymmärrät, milloin sitä on järkevää käyttää. Käytä sitä aina, kun tulostat tai muuten liität tekstiä (muuttujia) HTML-koodin sekaan. Yleensä funktiokutsu tulee siis echon perään (echo htmlspecialchars($muuttuja);) tai muuhun vastaavaan tilanteeseen.
1. Olio-ohjelmointi on tapa järjestellä ja jaotella ohjelma loogisiin kokonaisuuksiin siten että koodia voidaan tarvittaessa myös laajentaa ja muokata ilman että samaa koodia pitäisi toistaa useita kertoja. Olio-ohjelmointia ei tarvitse käyttää missään tilanteessa, jos ei halua, siinä mielessä että olisi jotain toiminnallisuutta jota ei voisi toteuttaa ilman olioita. On varmasti muitakin hyviä tapoja jäsennellä ohjelma mutta olio-ohjelmointi on yksi erittäin suosittu. Itse käyttäisin olio-ohjelmointia aina jos projektin koko, tulevaisuuden muutostarpeet mukaanlukien, on oletettavasti yli 50 riviä koodia.
Edit. 3. Tietokannassa on enemmän haittaa kuin hyötyä vaihtoehdosta b. Lisäksi a vie tässä tapauksessa noin puolta vähemmän tilaa.
lainaus:
a) <b>Bold</b>
b) <b>Bold</b>
Mutta sitten onkin väliä, miten nuo laitetaan tulemaan selaimelle, nimittäin käyttäjä näkee ne näin:
lainaus:
a) Bold
b) <b>Bold</b>
Edellisissä ei vielä ollut mitään vaarallista, mutta entä miten tätä voi käyttää.
a) <a href="javascript:...">linkki</a> b) <a href="javascript:...">linkki</a>
Käyttäjä näkee ne edelleen näin:
lainaus:
linkki
<a href="javascript:...">linkki</a>
Eli kuten Metabolix jo sanoikin, sitä käytetään lähinnä echon kanssa.
Tuohon ykköskohtaan voisin sanoa sen verran, että kun oikeasti omaksuu tuon olioparadigman käytön, niin silloin ei tarvitse enää miettiä, että mihin olioita käytetään...tämän voin sanoa ihan omasta kokemuksestani. Kuitenkin on syytä huomata, että oliot ovat oikeastaan vain muuttujia, joiden tyyppinä on vain jokin luokka eli silloin kyseessä on abstraktitietotyyppi eli jos olioita verrataan primitiivisiin tyyppeihin, kuten integeriin, niin merkittävin ero on se, että oliot kykenee säilyttämään muistissa isojakin kokoelmia dataa ja metodien avulla käsittelemään sitä, kun taas integer pystyy säilyttämään sen (yleensä) 32 bittisen kokonaisluvun. Eli kyseessä on vain rakenteinen tietotyyppi, jolla pystytään varsin kätevästi mallintamaan erilaisia reaalimaailman (tai ei reaalimaailman) oliota, kuten autoa, eläintä jne...
Triton kirjoitti:
...kun oikeasti omaksuu tuon olioparadigman käytön, niin silloin ei tarvitse enää miettiä, että mihin olioita käytetään...
Totta.
jukkah kirjoitti:
Tietokannassa ei ole mitään haittaa (eikä hyötyäkään) vaihtoehdosta b.
Mitä ihmettä? Tietenkin siitä on haittaa! Tieto on kannassa väärässä muodossa, joten tiedon hakeminen ja käsittely on vaikeampaa. Minusta ainakin olisi suuri ongelma, että hakusanalla "<b>" ei löydy esimerkkinä käyttämääsi riviä. Tietysti ongelman voi "korjata" tekemällä myös haun väärin, mutta se nyt on suunnilleen yhtä fiksua kuin laskea kertolasku a*b kaavalla e^(ln(a)+ln(b)). Tulee vain turhaa työtä, paljon sotkua ja ennemmin tai myöhemmin luultavasti myös virheitä koodiin. Ja mitä tapahtuukaan, kun halutaan tulostaa sivulle vaikkapa kannassa olevan tiedon pituus tai halutaan liittää tieto jonnekin muualle kuin HTML-sivulle?
Metabolix kirjoitti:
Mitä ihmettä? Tietenkin siitä on haittaa! Tieto on kannassa väärässä muodossa, joten tiedon hakeminen ja käsittely on vaikeampaa.
Ajattelin sitä vain periaatetasolla. Käytännössä varmoja haittoja ovat ylimääräinen käsittelyntarve (1ms per suorituskerta?), turhan tilan tarve tietokannassa, koodin luettavuuden todennäköinen hakaloituminen sekä virheriskin kasvaminen, ym. skenaariosta riippuen.
Edit. Muokkasin ko. viestiä.
Okei, ilmeisesti en omaksu ihan täysin tuota olio-ohjelmointia(ehkä kun vielä jokin verran yritän). Mutta lisää kysymyksiä, ehkä vähän turhiakin:
Onko järkevämpää käyttää pdo:ta, kuin sitä 'perus' MySQL? Siis pdo:llahan voi tehdä kyselyjä muihinkin kantoihin, kuin MySQl:n, mutta onko siinä kaikkia niitä tarpeellisia ominaisuuksia, kuin MySql:ssä?
Jos PDO:sta puuttuu jotain, se saattaa olla hankalasti toteutettavissa turvalliseksi, eli aina PDO "käsin säätämisen" sijaan.
Edit. Tämä on siis käsitykseni PDO:sta, vaikka en ole sitä koskaan käyttänyt (toistaiseksi).
PDO ei itsessään vielä takaa turvallista tietokantasovellusta, vaan taustalla on se perusajatus, että kehittäjä ymmärtää tietokantojen tietoturvaominaisuuksien päälle. Sama tiedon sanitointi, mikä PDO:ssa hoidetaan parametrisoinnilla, voidaan hoitaa myös MySQLi:ssä (MySQL Improved Extension) samaisella menetelmällä tai sitten arvojen eskapoinnilla. Saman sanitoinnin voi tehdä myös sillä perus MySQL APIlla, mutta suositeltavaa on kuitenkin käyttää vähintään MySQLi:tä. Parametrisoinnissa PDO ja MySQLi toimivat kovin samalla tavalla:
<?php
// Huom. testaamaton esimerkki
$host = "localhost";
$user = "my_user";
$password = "my_password";
$database = "world";
$query = "SELECT Something FROM Somewhere WHERE Id=?";
$id = '5uamdaed';
/* PDO */
try {
$pdo = new PDO("mysql:dbname={$database};host={$host}", $user, $password);
$statement = $pdo->prepare($query);
$statement->bindValue(1, $id, PDO::PARAM_STR);
$statement->execute();
$something = $statement->fetchAll(PDO::FETCH_NAMED);
} catch (PDOException $e) { }
/* MySQLi */
$mysqli = new MySQLi($host, $user, $password, $database);
//...
$statement = $mysqli->stmt_init();
if ($statement->prepare($query)) {
$statement->bind_param("s", $id);
$statement->execute();
$statement->bind_result($something);
$stmt->fetch();
}PDO tukee toki myös referenssinä bindausta sekä bindattavien arvojen tuomista ryppäissä esim. PDOStatement::executelle. Erottavista tekijöistä ensimmäinen on se, että PDO tosiaan tukee useita tietokanta-ajureita, kun MySQLi on nimensä mukaisesti tarkoitettu MySQL-tietokannan käpristelyyn ja sisältää täten funktioita, jotka liittyvät ko. kantaan. Toinen tekijä on nopeusero PDOn ollessa hitaampi, johon kannattanee kuitenkin kiinnittää huomiota vasta sitten, kun ollaan oikeasti todettu PDO:n olevan syypää hitauteen muiden mahdollisten pullonkaulojen, kuten huonon kantarakenne- ja kyselysuunnittelun sijaan.
Okkei. No onko järkevää käyttää aina tuossa PDO/MySQL-kyselyn kanssa try-catch virheiden käsittelyä, vaiko tarkistaa palautettujen rivien määrä?
<?php if ($kysely->rowCount() == 0) { $virhe = "Kyselyssä tapahtui virhe"; } ?>
dartvaneri kirjoitti:
Okkei. No onko järkevää käyttää aina tuossa PDO/MySQL-kyselyn kanssa try-catch virheiden käsittelyä, vaiko tarkistaa palautettujen rivien määrä?
<?php if ($kysely->rowCount() == 0) { $virhe = "Kyselyssä tapahtui virhe"; } ?>
Siis? Poikkeusten käsittely ei ole vapaavalintainen ominaisuus. Jos käytettävät kutsut voivat heittää poikkeuksia, joiden et halua kaatavan ohjelmaa, niin ne on pakko käsitellä try-catch-rakenteessa. PDO ei itse kuitenkaan viskele poikkeuksia ihan hillittömästi.
RowCount():n perusteella et voi kuitenkaan päätellä, onko kyselyssä tapahtunut virhe vai eikö rivejä vain löytynyt yhtään. Execute() ja prepare() palauttavat falsen, jos kyselyn suorittamisessa on tapahtunut virhe.
Itse olen alkanut käyttää poikkeuksia ihan siitä syystä, että on mukavampaa laittaa yksi try-catch-lohko kuin tarkistaa jokaisen kyselyn jälkeen erillisessä if-lohkossa jokaisen kyselyn onnistuminen erikseen.
Vrt.
$ok = $dataObject->databaseOperationX(); if ($ok) { $ok = $dataObject->databaseOperationY(); if ($ok) { $ok = $dataObject->databaseOperationZ(); ... } } } // ----------- try { // Jokainen operation-metodi heittää poikkeuksen epäonnistuessaan $dataObject->databaseOperationX(); $dataObject->databaseOperationY(); $dataObject->databaseOperationZ(); } catch (DataObjectException $x) { ... }
P.S. Alahan koodata englanniksi kun vielä kerkiät, niin säästyt monelta kirosanalta myöhemmässä elämässä.
Ihan ensiksi kannattaa mielessä erottaa käyttäjän virheet ja todelliset virheet toisistaan. Rivien määrä voi kertoa käyttäjän tekemästä virheestä, esimerkiksi käyttäjä on kirjoittanut sanan väärin ja haku ei löydä yhtään riviä. Silloin järjestelmässä ei ole mitään vikaa eikä mitään todellista virhettä tapahdu.
Poikkeukset kertovat yleensä väärin kirjoitetusta kyselystä tai jostain palvelimen viasta. Keksin tähän hätään vain kaksi tilannetta, joissa PDO:n poikkeus voi tapahtua ilman varsinaista virhettä: kun FOREIGN KEY estää rivin poiston tai kun UNIQUE KEY estää rivin lisäyksen. Muissa tilanteissa poikkeusta ei ole järkeä käsitellä paikallisesti, vaan sivun toiminnan voi katkaista saman tien, koska joko koodissa on bugi tai palvelin ei toimi oikein.
Esimerkiksi Ohjelmointiputkassa ei ole yhtään kohtaa, jossa tarkistettaisiin PDO:n poikkeukset, koska niitä ei pitäisi koskaan tulla. Ne poikkeukset, joita ei erikseen oteta kiinni, käsitellään tähän rekisteröidyllä funktiolla (ks. set_exception_handler). Ohjelmointiputkassa käsittelyfunktio ilmoittaa virheestä ylläpitäjille ja kertoo käyttäjälle, että sivustolla on tapahtunut virhe.
Okei, tämä try-catch taitaapi olla selvä.
The Alchemist kirjoitti:
P.S. Alahan koodata englanniksi kun vielä kerkiät, niin säästyt monelta kirosanalta myöhemmässä elämässä.
Ok, mutta mikä tulee aiheuttamaan kiroilua? (jotain pientä arvelua on, mutta enpä ala heitteleen.)
Edit. Ja tarkoitatko muuttujien nimiä, vai myöskin kommentteja englanniksi?
En tarkoita pelkästään muuttujien nimiä enkä tarkoita myöskään kommentteja. Koodaus on hyvin paljon muuta kuin muuttujia ja kommentteja.
"$Kysely->rowCount()" ei ole missään mielessä järkevän näköinen. Vielä vähemmän olisi "$Kysely->rivienMaara()". Saati sitten "$ksl->rivienMaara()". Ohjelmointikielet ovat luonteeltaan englanninkielisiä, joten on vain koherenttia käytöstä käyttää englantia omissa nimeämiskäytännöissään.
Kirosanat tulisivat joko sinulta, kun myöhemmin tulet asian ymmärtämään, tai sitten kaikilta muilta, jotka koodiasi joutuvat lukemaan.
Tarkennetaan vielä, että jos koodi on vain omaan käyttöön, niin sillä ei ole mitään väliä millä kielellä muuttujat ym. ovat. Heti kun koodilla on mahdollisuus joutua jakoon, niin asiat muuttuvat aika valtavasti... on ollut todella ärsyttävä koettaa pysyä vaikkapa saksaksi tai ranskaksi kirjoitetusta koodista kärryillä, saati sitten japaniksi.
Ohjelmoinnin kieli on englanti, kaikki hyödyllinen materiaali on saatavilla englanniksi ja vakiintunut termistökin on englantikeskeistä. Eli kannattaa vaikka pyöriä englanninkielisillä irkkikanavilla ja foorumeilla, lukea englanninkielistä kirjallisuutta (jo yhdenkin kirjan läpikahlaus tekee hyvää), katsoa elokuvia ja sarjoja ilman tekstitystä... yllättävän nopeasti sitä oppii lopulta kunhan kiusaa säännöllisesti aivojaan. Koulu ei yksinään auta englannin oppimisessa, esimerkiksi suurin osa omasta kielitaidostani on tullut sen jälkeen kun valmistuin kymmenisen vuotta sitten.
Sitten taas kun tehdään vaikka suomalaiselle yritykselle räätälöityä järjestelmää ja yrityksellä käytetään termejä joita kukaan ei tiedä englanniksi tai englanninnos ei ole yhtä yksiselitteinen tai kuvaava, niin mielestäni on järkevämpää mahdolliset siihen liittyvät luokat tai muuttujat nimetä käyttäen sitä suomenkielistä nimeä, kuin vääntää väkisin jotain englanniksi.
Minusta on lähinnä surkuhupaisaa, jos suomenkieliset ohjelmoijat käyttävät keskenään englantia, koska "se on ohjelmoinnin kieli". Englanti on vain kieli muiden joukossa, ja on pelkkä sattuma, että ohjelmointikielten avainsanat ovat yleensä englanniksi. Ei ole mikään ohjelmoijan luonnollinen kehityskaari, että siirtyy jossain vaiheessa koodaamaan englanniksi.
Harva suomalainen pystyy kirjoittamaan nopeasti virheetöntä tekstiä englanniksi. Ei näytä hyvältä, jos englanninkielisessä dokumentaatiossa vilisee siellä täällä pieniä kielivirheitä.
Mä oon Grezin ja Antin kans aika vahvasti eri mieltä. Huonokin kieli koodissa on parempi kuin kieli jota ei ymmärrä ollenkaan ja huonoja käännöksiä voi aina selittaa kommenteilla. Sitäpaitsi jos koodi kirjoitettaisiin kokonaan suomeksi niin noita sopivien käännösten puuttumisia tulisi vastaan varmasti paljon enemmän kuin kokonaan englanniksi kirjoitettaessa vaikka kyseessä olisikin erityisesti suomalaiselle yritykselle räätälöity ohjelma. Kysymys ei ole pelkästään siitä että englanti olisi "se ohjelmoinnin kieli" vaan siitä että englanti on se lähes de facto-kieli, jota ihmiset käyttävät keskenään jos heillä ei ole yhteistä natiivikieltä.
Mä oon ollut useammassakin työpaikassa joissa lähdekoodia on kirjoittanut tai joutunut lukemaan suomenkieltä taitamaton työntekijä ja englanniksi se on heiltä onnistunut. Ja vaikka juuri koodaushetkellä tarvetta ei olisikaan, niin myöhemmin sellainen voi tulla vastaan esim. palkattaessa henkilöstöä, ulkoistettaessa kehitystyötä tai vaikkapa myytäessä koko liiketoiminta. Ja koska lähes kaikki varteenotettava ohjelmoinnin koulutusmateriaali ja ulkopuoliset ohjelmakirjastot ovat englanniksi, minusta on myös perusteltua vaatia riittävää englannintaitoa työkseen ohjelmoivilta. Toisinpäin laitettuna: yhdessäkään nykyisessä tai aiemmassa työpaikassani ei olisi tullut kysymykseenkään kirjoittaa koodia suomeksi.
Em. syistä myös api-dokumentaatio ja muu ohjelmistokehitykseen liittyvä dokumentaatio pitäisi olla englanniksi. Käyttäjädokumentaatio on sitten asia erikseen ja jos Antti tarkoitti viimeisellä kommentillaan sitä niin en ymmärrä miten se tähän aiheeseen liittyy.
Tukki kirjoitti:
Mä oon ollut useammassakin työpaikassa joissa lähdekoodia on kirjoittanut tai joutunut lukemaan suomenkieltä taitamaton työntekijä ja englanniksi se on heiltä onnistunut.
Ei oo kyllä kovin kaksinen kooderi eikä kovin hyvin dokumentoitu projekti, jos homma kaatuu siihen, että yhden muuttujan tai luokan nimi on Tukki sen sijaan että olisi Log. Ja huomautan vielä, että asialla ei ole mitään tekemistä lokin kanssa. (Tässä tapauksessa vieläpä sanalle tukki löytyi täydellinen englanninkielinen vastine, joten ei edes täysin vastaa kuvaamaani tilannetta)
Mitä tulee tuohon Antin pointtiin, että kaikki ei välttämättä ole hyviä kirjoittamaan englanninkielistä tekstiä -> saattaa tulla jopa parempaa jälkeä jos kirjoittaa suomeksi ja konekääntää vaikka google translaterilla. Onko sitten parempi että laitetaan talteen se suomenkielinen vai konekäännetty englanninkielinen? Tietenkin jos dokumentaatiota annetaan ulos, niin silloin tarvittaessa käytetään teknistä kirjoittajaa ja kääntäjää apuna.
Tosin käytännössä en kyllä ole työskennellyt sellaisen koodarin kanssa, jolta ei taipuisi englanniksi dokumentointi.
Minulta sujuu aika hyvin dokumentit englanniksikin. Joskus tosin joku asia on helpompi kirjoittaa ensin suomeksi ja kääntää siitä englanniksi.
Antti Laaksonen kirjoitti:
Minusta on lähinnä surkuhupaisaa, jos suomenkieliset ohjelmoijat käyttävät keskenään englantia, koska "se on ohjelmoinnin kieli". Englanti on vain kieli muiden joukossa, ja on pelkkä sattuma, että ohjelmointikielten avainsanat ovat yleensä englanniksi. Ei ole mikään ohjelmoijan luonnollinen kehityskaari, että siirtyy jossain vaiheessa koodaamaan englanniksi.
Harva suomalainen pystyy kirjoittamaan nopeasti virheetöntä tekstiä englanniksi. Ei näytä hyvältä, jos englanninkielisessä dokumentaatiossa vilisee siellä täällä pieniä kielivirheitä.
Ei ihminen voi ohjelmoida kuin englanniksi tai siansaksaksi, kuten sanoin jo aiemmin. Kaikki valmiit funktiot, luokat ja kaikki mahdollinen on englanniksi. Jos alat soveltaa omiasi ja pupellat sekaan suomea, niin se on ainoastaan häiritsevää ja hankaloittaa koodin lukemista.
Kommentit kirjoittaisin itse ihan sillä kielellä, mikä on kyseisen koodin kanssa puljaavien kehittäjien natiivi kieli. Tosin kotiprojektini työstän aina alusta loppuun englanniksi.
P.S. Ihan yhtä veemäistä on lukea suomenkielisiä kommentteja, joissa vilisee kirjoitusvirheitä. Hyvin harvassa ovat ne koodarit, jotka osaisivat edes suomea, kun ei ole kääntäjää pakottamassa syntaksia.
Suomeksi on aivan hyvä ohjelmoida, jos itse tykkää. Englanniksi voi ohjelmoida, jos siltä tuntuu tai jos projekti on englanniksi. Kaikkein suurin häpeä on, jos ei osaa mukisematta kirjoittaa eri tilanteissa eri kielillä.
Laittakaahan tämä omaan aiheeseen, niin minäkin tuon oman korteni kekoon. :)
Tukki kirjoitti:
Sitäpaitsi jos koodi kirjoitettaisiin kokonaan suomeksi niin noita sopivien käännösten puuttumisia tulisi vastaan varmasti paljon enemmän - -
Suomen kieli ei ole vajavainen englantiin verrattuna, vaan samat asiat on mahdollista ilmaista englanniksi ja suomeksi.
Tukki kirjoitti:
Mä oon ollut useammassakin työpaikassa joissa lähdekoodia on kirjoittanut tai joutunut lukemaan suomenkieltä taitamaton työntekijä ja englanniksi se on heiltä onnistunut. Ja vaikka juuri koodaushetkellä tarvetta ei olisikaan, niin myöhemmin sellainen voi tulla vastaan esim. palkattaessa henkilöstöä, ulkoistettaessa kehitystyötä tai vaikkapa myytäessä koko liiketoiminta.
Toki, mutta näin ajateltuna yhtään mitään ei kannattaisi kirjoittaa suomeksi, koska aina on mahdollisuus, että myöhemmin joku suomea osaamaton haluaa lukea sen.
Tukki kirjoitti:
Käyttäjädokumentaatio on sitten asia erikseen ja jos Antti tarkoitti viimeisellä kommentillaan sitä niin en ymmärrä miten se tähän aiheeseen liittyy.
Minusta on hassua, jos suomenkieliset ohjelmoijat käyttävät keskenään tankeroenglantia edes dokumenteissa, joita ei julkaista ulkopuolisille.
The Alchemist kirjoitti:
Jos alat soveltaa omiasi ja pupellat sekaan suomea, niin se on ainoastaan häiritsevää ja hankaloittaa koodin lukemista.
Asia on juuri päinvastoin. Kun ohjelmointikielen valmiskalusto on englanniksi ja omat tuotokset ovat suomeksi, niin ne eivät mene sekaisin keskenään.
Antti Laaksonen kirjoitti:
Tukki kirjoitti:
Mä oon ollut useammassakin työpaikassa joissa lähdekoodia on kirjoittanut tai joutunut lukemaan suomenkieltä taitamaton työntekijä ja englanniksi se on heiltä onnistunut. Ja vaikka juuri koodaushetkellä tarvetta ei olisikaan, niin myöhemmin sellainen voi tulla vastaan esim. palkattaessa henkilöstöä, ulkoistettaessa kehitystyötä tai vaikkapa myytäessä koko liiketoiminta.
Toki, mutta näin ajateltuna yhtään mitään ei kannattaisi kirjoittaa suomeksi, koska aina on mahdollisuus, että myöhemmin joku suomea osaamaton haluaa lukea sen.
Tarkoitus oli osoittaa että ohjelmistoalalla on hyvin yleistä, ehkä yleisempää kuin monilla muilla aloilla, että samassa työyhteisössä on myös suomea taitamattomia työkavereita ja että suomenkielisiltäkin vaaditaan riittävää englannin osaamista. Tässä valossa ja omien kokemuksienikin pohjalta argumenttisi on ihan totta: mitään dokumentteja mitä ei ole erityisesti tarvinnut kirjoittaa suomeksi ja millä on kuviteltu olevan vähänkin pidempi elinkaari ei yleensä ole kirjoitettu kuin englanniksi.
Antti Laaksonen kirjoitti:
Tukki kirjoitti:
Käyttäjädokumentaatio on sitten asia erikseen ja jos Antti tarkoitti viimeisellä kommentillaan sitä niin en ymmärrä miten se tähän aiheeseen liittyy.
Minusta on hassua, jos suomenkieliset ohjelmoijat käyttävät keskenään tankeroenglantia edes dokumenteissa, joita ei julkaista ulkopuolisille.
Minusta on vielä hassumpaa, jos englantia taitavat suomenkieliset ohjelmoijat kirjoittavat dokumentteja ja lähdekoodia sekakielellä (kokonaan suomi ei ole vaihtoehto koska avainsanat, ulkoiset kirjastot, generoidut tekstit ja ennenkaikkea kontekstin ymmärtämiseen vaadittava kirjallisuus on lähes väkisinkin englantia). Tällöin dokumenttien lukemiseen ja ohjelmiston kehittämiseen vaaditaan keinotekoisesti sekä suomen että englannin osaamista, kun todellisuudessa pelkkä englanti riittäisi. Ohjelmiston lähdekoodi ja siihen liittyvä dokumentaatio ei oikeasti ole niin kovin monimutkaista kieltä etteikö sitä pystyisi tuottamaan keskinkertaisellakin kielipäällä ihan ymmärrettävästi. Ja jos joku ei pysty, niin minusta hän ei täytä ammattilaiselta vaadittavia kriteerejä.
Antti Laaksonen kirjoitti:
Asia on juuri päinvastoin. Kun ohjelmointikielen valmiskalusto on englanniksi ja omat tuotokset ovat suomeksi, niin ne eivät mene sekaisin keskenään.
Tämä onkin hieno argumentti jota voisi vähän laajentaa. Tästä eteenpäin jokainen koodari lisää muuttujien, metodien ja luokkien nimiin firman nimen, oman nimensä ja luontipäivämäärän niin pysyy tuotokset järjestyksessä.
Näin:
<?php
namespace Acme\Tukki\Päivämäärätyökalut;
/**
* @author Tukki
*/
class AcmeTukki20120405PäivamääräAika extends \DateTime {
/**
* Staattinen funktio, joka palauttaa kutsuhetken päivämäärää
* esittävän olion parametrina annetulla aikavyöhykkeellä.
*
* @param \DateTimeZone $aikavyöhyke
* @return AcmeTukki20120405PäivamääräAika kutsuhetken päivämäärää annetulla aikavyöhykkeellä.
*/
public static function AcmeTukki20120405Tänään(\DateTimeZone $acme_tukki_20120504_aikavyöhyke = null) {
if($acme_tukki_20120504_aikavyöhyke === null) {
return new AcmeTukki20120405PäivamääräAika();
}
else {
return new AcmeTukki20120405PäivamääräAika(null, $acme_tukki_20120504_aikavyöhyke);
}
}
}
$acme_tukki_20120405_tänään = AcmeTukki20120405PäivamääräAika::AcmeTukki20120405Tänään(new \DateTimeZone('Pacific/Kwajalein'));Hard Reset!
Tämä on Ohjelmointiputka. Suomenkielinen keskustelualue suomalaisille ohjelmoijille. Täällä on (tai pitäisi olla) ookoo lähettää koodia, joka on kirjoitettu suomeksi, ilman että siitä tulee nipotusta. Siitäkin huolimatta, että suomenkieltä koodissa on vaikea perustella muuhun kuin opetukseen, pieneen harrastuskäyttöön tai pienen yrityksen käytössä.
Laitteistonollaus.
Aihe on jo aika vanha, joten et voi enää vastata siihen.