Miten ammattilainen toimii, jos ohjelmointiprojektissa annetaan tiukat ehdot koodin ulkoasulle?
1. Opettelee kirjoittamaan huolellisesti suoraan halutulla tyylillä.
2. Kirjoittaa lähdekoodin muotoilijan, joka ajetaan automaattisesti ennen kuin koodia annetaan eteenpäin.
3. Onko kakkoskohdan muotoilijoita valmiina siten, että niitä voisi konfiguroida helposti?
1. Opettelee kirjoittamaan huolellisesti suoraan halutulla tyylillä.
2. Kirjoittaa lähdekoodin muotoilijan, joka ajetaan automaattisesti ennen kuin koodia annetaan eteenpäin.
3. Onko kakkoskohdan muotoilijoita valmiina siten, että niitä voisi konfiguroida helposti?
Vastaukset 7
Vanhimmat
Siihen on valmiit muotoilijat, sen kun käyttää vaan.
Ammattilaiset käyttävät niitä joka tapauksessa, vaadittiin sitä tai ei.
Ammattilaiset tietävät, että valmiit muotoilijat muotoilevat sellaisenkin koodin, jota ei pitäisi. Esimerkiksi taulukkoon nätisti listatut initialisointiarvot saattavat joutua pahaan mankeliin.
Heh.. Kaikkihan haluaisi kirjoitaa puhdasta nopeeta bugitonta koodia.
Harvalta se onnistuu, jotta erilaisia juttuja tarvitaan tarkastamaan koodia.
Lisäksi kaikkiea koodia ei ole järkevää itse tupeltaa viikotolkulla turhrata aikaa jos se on jo valmiina olemassa.
Tekoälykin apinoi jo valmista koodia!
On kuule niin erilaisia ohjelma taloja että välillä hirvittää!
Tieto on yksi, jossa laadunvarmistus on sitä, että ongelman jälkee huudetaan niin että hiukset lepattaa.
Jos ohjelmointiprojektissa ei anneta ehtoja koodin ulkoasulle, jotakin on pielessä. Ammattilainen luultavasti laatisi tai etsisi käsiinsä ohjeet koodin ulkoasulle ja hyväksyttäisi ne yrityksen tai projektin johdolla. On nimittäin suuri etu, jos kaikki projektiin osallistuvat kirjoittavat "samalla käsialalla".
Jos C-koodista jotain voi sanoa, niin ennen kuin pääsee koodaamaan muotoseikat on syytä lukea, koska jo include-lauseiden järjestys voi olla ennalta annettu. Tämän jälkeen tärkeintä on, että koodi toimii ts. menee läpi testeistä. Seuraavaksi koodin on oltava dokumentaation mukaista - tässä kohdassa voidaan käyttää jotain doxygen-tyylistä ratkaisua, joka luo lisää sääntöjä koodin kommentoinnille.
Jotta homma ei kävisi tylsäksi, pitää koodi vielä ajaa lintin läpi, joka poimii sieltä potentiaalisia virhekohtia: Ensimmäisellä ajokerralla esim. 200-rivin koodista voi löytyä 700 virhettä, joka siis pitää saada nollille.
Tämän jälkeen koodi pääsee katselmointiin, josta varmasti tulee vielä muutoksia siihen. Lopputuloksena pitäisi olla koodia, jota on helppo lukea(dokumentaatiota ei tarvita välttämättä), joka toimii ja jossa ei ole syntaksista johtuvia sudenkuoppia vaan rakenteet on korvattu helpommin luettavilla eli yhtenäisellä tavalla läpi koodin.
Seurauksena pitäisi olla koodia, joka on selkeää kaikille projektiin osallistujille eli vaikka jotakin featurea ei olisikaan itse koodannut koodiin pääsee sisälle melko pienellä vaivalla.
Visual Studio 2019 eteenpäin muotoilee automaattisesti omat template-projektitkin projektin avatessa, halusit tai et, siksi vaihdoin alaa. Koska standardi-muotoilu on lukukelvotonta.
Vanhemmissa versioissa ctrl+...