Include&linkitys viallisuuden selvitys&korjaus

Ei tosiaankaan ole hölmö ajatus. Sillä olisi oikeaa käyttöä esim. viallisten lähdekoodipakettien korjaamisessa tai viallisuuden kiertämisessä.

Vastaavaa systeemiä voi käyttää myös nimikonfliktien mahdollisuuden tunnistamisessa, ilman että tarvitsee tehdä lähdekoodeja joista kääntäjä antaa virheilmoituksen.

On muuten väärä ja tehoton käytäntö sanoa ideaa vain hölmöksi tai ehkä hölmöksi. Idean kuvailun luonteeseen kuuluu lähes väistämättä itsessään se mahdollisuus, että idea on toimimaton tai kannattamaton. Jos se toimimattomuus tai kannattamattomuus on jonkun mielestä niin helposti nähtävissä, että se helppous laskee idean tasolle "hölmö", niin sitten pitäisi olla myös helposti kuvailtavissa mikä tekee ideasta toimimattoman tai kannattamattoman. Ja melkein jokainen idea on jossain vaiheessa jollain tavalla "ehkä hölmö", jos "ehkä" tarkoittaa jotain todennäköisyyttä tehottomuudelle tai kannattamattomuudelle jonka joku joukko ihmisiä pystyy näkemään helposti. Sen tehottomuuden tai kannattamattomuuden syyn kuvailu muuten auttaa kuvailijaa itseäänkin ymmärtämään aihetta paremmin.

Edellinen kuvaus on karkea. En ole kuvaillut asiaa täydellisesti. Kuvauksessa tai sen taustalla olevissa oletuksissa saattaa olla mukana myös virhe tai käsitys jonkun sanan merkityksestä, josta jollain toisella on eri käsitys. Siksi jollekulle saattaa tulla käsitys, että edellinen selitys on typerä, mutta jos niin käy, sitten on viisainta yrittää selittää ja analysoida käsityksen syitä, missä on mahdollisesti virhe tai mielipide-ero.

gdngvn kirjoitti:

Ei tosiaankaan ole hölmö ajatus. Sillä olisi oikeaa käyttöä esim. viallisten lähdekoodipakettien korjaamisessa tai viallisuuden kiertämisessä.

Vastaavaa systeemiä voi käyttää myös nimikonfliktien mahdollisuuden tunnistamisessa, ilman että tarvitsee tehdä lähdekoodeja joista kääntäjä antaa virheilmoituksen.

On muuten väärä ja tehoton käytäntö sanoa ideaa vain hölmöksi tai ehkä hölmöksi. Idean kuvailun luonteeseen kuuluu lähes väistämättä itsessään se mahdollisuus, että idea on toimimaton tai kannattamaton. Jos se toimimattomuus tai kannattamattomuus on jonkun mielestä niin helposti nähtävissä, että se helppous laskee idean tasolle "hölmö", niin sitten pitäisi olla myös helposti kuvailtavissa mikä tekee ideasta toimimattoman tai kannattamattoman. Ja melkein jokainen idea on jossain vaiheessa jollain tavalla "ehkä hölmö", jos "ehkä" tarkoittaa jotain todennäköisyyttä tehottomuudelle tai kannattamattomuudelle jonka joku joukko ihmisiä pystyy näkemään helposti. Sen tehottomuuden tai kannattamattomuuden syyn kuvailu muuten auttaa kuvailijaa itseäänkin ymmärtämään aihetta paremmin.

Edellinen kuvaus on karkea. En ole kuvaillut asiaa täydellisesti. Kuvauksessa tai sen taustalla olevissa oletuksissa saattaa olla mukana myös virhe tai käsitys jonkun sanan merkityksestä, josta jollain toisella on eri käsitys. Siksi jollekulle saattaa tulla käsitys, että edellinen selitys on typerä, mutta jos niin käy, sitten on viisainta yrittää selittää ja analysoida käsityksen syitä, missä on mahdollisesti virhe tai mielipide-ero.

Lue lisää

Niin ja jos toinen esittää argumentin idean toimimattomuuden, tehottomuuden tai kannattamattomuuden puolesta joka tuntuu idean esittäjästäkin idean kaatavalta argumentilta, niin kolmas osapuoli voi keksiä tavan välttää tai kiertää väitetty ongelma. Se välttö tai kierto lisää idean kompleksisuutta, mutta ei silti välttämättä tee ideasta kannattamatonta.

Mitä tulee niiden lähdekoodien toimimaan saamiseen, mistä puuttuu osa headereista tai ei tiedetä miten linkitetään, niin ehkä se "hölmöksi" sanoja tietää jonkun käyttöjärjestelmään kuuluvan vakiotavan miten sellaista ongelmaa käsitellään, mutta jos sellainen on, se ei ole läheskään kaikkien tiedossa. Siksi on virheellistä haukkua idean esittäjän henkisiä kykyjä sanomalla ideaa "hölmöksi". Sellaisen tiedon puuttuminen ei ole merkki henkisten kykyjen vajavaisuudesta. Voi ehdottaa, että kokeilee eri headereita, mutta onko vajaamielisyyden merkki jos varovaisesti ehdottaa, että ehkä sen kokeilun voisi automatisoida?

Totta kai on tehokkaampia tapoja tarkistaa headerien ja linkitysten oikeellisuus kuin syöttää lähdekoodi gcc:lle, mutta sen tehokkaamman tavan huomiointi ei ole välttämätöntä pääidean kommunikoinnissa. Vaikka onkin tehokkaampi tapa, ei ole itsestään selvää että se on ohjelmointivaivan arvoista.

Ei paljon haittaa jos scriptiltä tai ohjelmalta menee koko päivä tai vaikka koko viikko eri vaihtoehtojen kokeiluun. Siinä se menisi sivussa pienellä prioriteetilla tai konetta odotellessa voi mennä uimaan tms.

Deopuk kirjoitti:

Niin ja jos toinen esittää argumentin idean toimimattomuuden, tehottomuuden tai kannattamattomuuden puolesta joka tuntuu idean esittäjästäkin idean kaatavalta argumentilta, niin kolmas osapuoli voi keksiä tavan välttää tai kiertää väitetty ongelma. Se välttö tai kierto lisää idean kompleksisuutta, mutta ei silti välttämättä tee ideasta kannattamatonta.

Mitä tulee niiden lähdekoodien toimimaan saamiseen, mistä puuttuu osa headereista tai ei tiedetä miten linkitetään, niin ehkä se "hölmöksi" sanoja tietää jonkun käyttöjärjestelmään kuuluvan vakiotavan miten sellaista ongelmaa käsitellään, mutta jos sellainen on, se ei ole läheskään kaikkien tiedossa. Siksi on virheellistä haukkua idean esittäjän henkisiä kykyjä sanomalla ideaa "hölmöksi". Sellaisen tiedon puuttuminen ei ole merkki henkisten kykyjen vajavaisuudesta. Voi ehdottaa, että kokeilee eri headereita, mutta onko vajaamielisyyden merkki jos varovaisesti ehdottaa, että ehkä sen kokeilun voisi automatisoida?

Totta kai on tehokkaampia tapoja tarkistaa headerien ja linkitysten oikeellisuus kuin syöttää lähdekoodi gcc:lle, mutta sen tehokkaamman tavan huomiointi ei ole välttämätöntä pääidean kommunikoinnissa. Vaikka onkin tehokkaampi tapa, ei ole itsestään selvää että se on ohjelmointivaivan arvoista.

Ei paljon haittaa jos scriptiltä tai ohjelmalta menee koko päivä tai vaikka koko viikko eri vaihtoehtojen kokeiluun. Siinä se menisi sivussa pienellä prioriteetilla tai konetta odotellessa voi mennä uimaan tms.

Lue lisää

Kyllä se ohjelmistokehitys pitää tehdä hallitusti eli käyttää versionhallintaohjelmia (kuten cvs/svn/git) ja versioleimoja projektinlaajuisesti. Näillä leimoilla koodin voi getata ulos niin, että saadaan virallinen yhteentoimiva paketti. Koko homma karkaa käsistä, jos tästä luovutaan (ja koodeja ottaa ulos useampi kuin yksi henkilö).
Kehittäjät voi toki getata tippejä (viimeisiä sorsaversioita) ja ajaa versionhallintaohjelman diffit että näkee mitä on muutettu ja leimata testiversiot devel-leimalla = koodit mistä sitten tehdään virallinen käännös/leimaus, mutta kaikki viralliseen jakoon menevä koodi pitäisi ohjeistaa otettavaksi virallisella leimalla ulos (tipit ei välttämättä käänny), tai viralliset versiot pitäisi kopioida toiseen, "viralliseen repositoryyn".
Tuo alkuperäinen ehdotus ei täytä mitään laatujärjestelmän kriteereitä.