Onko koskaan hyvä idea koodata arvoja sovelluksiimme?

Kyllä, mutta tee siitä ilmeinen .

Tee:

• käytä -vakioita
• käytä kuvaavaa muuttujan nimi

Älä:

• ole maagisia numeroita kelluva koodin ympärillä

Kommentit

• Mikä on puhtaampaa, diameter = 2 * radius tai diameter = RADIUS_TO_DIAMETER_FACTOR * radius? On todellakin kulmatapauksia, joissa maaginen numero voi olla parempi ratkaisu.
• En voi ’ olla samaa mieltä tämä vastaus riittää. Minulla on tapana ajatella ohjelmointia kuin olla kirjailija. Kerrot tarinasi koodin kautta ja jos ihmiset eivät ymmärrä logiikkaa, se tekee koodistasi mielestäni arvoton. Että ’ s miksi hyvin harkitut nimeämiskäytännöt ovat lähinnä luettavuutta varten. Ei ole myöskään hyvää syytä käyttää maagisia numeroita. Käyttämällä maagisia numeroita poistat ” miksi ” yhtälöstä ja vaikeuttaa alittamista tand. Esimerkiksi: ” halkaisija = 2 * säde ” Mille tarkoitetaan kahta? Tällä ” halkaisija = RADIUS_TO_DIAMETER_FACTOR * säde ” on paljon järkevämpää.
• halkaisija = 2 * säde on suoraan lukion matematiikka. Syy siihen, miksi ” 2 ” ei nimetä, on se, että jos sillä on arvoa muulle, se vaatii muutosta fysiikka tai matematiikka tai molemmat. (Toisaalta Pi: n tai Plancks-vakion nimeäminen on hyvä liike yksinkertaisen luettavuuden vuoksi.)
• @Joonas: Pfft. Tarkoitatko varmasti diameter = radius << 1? Oletan, että se voi olla myös diameter = radius << RADIUS_TO_DIAMETER_BITS_TO_SHIFT.
• miten ’ käy läpi joitain diameter = radius.toDiameter()

Mikä on mielestäni outoa tässä Q & Tähän mennessä kukaan ei ole yrittänyt määritellä selkeästi ”kovakoodia” tai, mikä tärkeintä, vaihtoehtoja.

tl; dr : Kyllä, arvojen koodaaminen on joskus hyvä idea, mutta ei ole yksinkertaista sääntöä milloin ; se riippuu täysin kontekstista.

Kysymys supistaa sen arvoihin , joiden tarkoitan tarkoittavan maagisia numeroita , mutta vastaus siihen, ovatko he hyvä idea vai eivät, suhteessa mihin he tosiasiallisesti käyttävät!

Useita esimerkkejä kovakoodatuista ”arvot ovat:

• Määritysarvot

  Rypistelen aina, kun näen lausuntoja kuten command.Timeout = 600. Miksi 600? Kuka sen päätti? Oliko se aikakatkaisua aikaisemmin, ja joku nosti aikakatkaisua hakkerointina sen sijaan, että korjaisi taustalla olevan suorituskykyongelman? Vai onko se tosiasiallisesti jokin tunnettu ja dokumentoitu odotus käsittelyajasta?

  Näiden ei pitäisi olla maagisia numeroita tai vakioita, vaan ne tulisi ulkoistaa kokoonpanotiedostoon tai tietokantaan jossain merkityksellinen nimi, koska niiden optimaalisen arvon määrää suurelta osin tai kokonaan ympäristö, jossa sovellus on käynnissä.

• Matemaattiset kaavat

  Kaavat ovat yleensä melko staattisia, joten sisällä olevien vakioarvojen luonne ei ole erityisen tärkeä. Pyramidin tilavuus on (1/3) b * h. Välitämme, mistä 1 tai 3 tuli? Ei oikeastaan. Edellinen kommentaattori huomautti perustellusti, että diameter = radius * 2 on todennäköisesti parempi kuin diameter = radius * RADIUS_TO_DIAMETER_CONVERSION_FACTOR – mutta se on väärä kahtiajako.

  Tämäntyyppisissä tilanteissa sinun pitäisi tehdä toiminto . Minun ei tarvitse tietää, miten keksit kaavan, mutta minun on silti tiedettävä, mitä se tarkoittaa . Jos minkä tahansa yllä kirjoitetun hölynpölyn sijaan kirjoitan volume = GetVolumeOfPyramid(base, height), yhtäkkiä kaikki käy selvästi selvemmäksi, ja on ihan ok, jos maagiset numerot ovat sisällä funktio (return base * height / 3), koska on ilmeistä, että ne ovat vain osa kaavaa.

  Tässä avain on tietysti oltava lyhyt ja yksinkertainen funktio. Tämä ei toimi funktioilla, joissa on 10 argumenttia ja 30 laskentariviä. Käytä siinä tapauksessa funktiokoostumusta tai vakioita.

• iv Verkkotunnuksen / liiketoiminnan säännöt

  Tämä on aina harmaa alue, koska se riippuu arvon tarkkuudesta. Suurimman osan ajasta juuri nämä maagiset numerot ovat ehdokkaita vakioiksi muuttumiseen, koska se tekee ohjelmasta helpommin ymmärrettävää monimutkaistamatta ohjelmalogiikkaa. Harkitse testiä if Age < 19 vs. if Age < LegalDrinkingAge; luultavasti voit selvittää, mitä tapahtuu ilman vakiota, mutta kuvailevalla on helpompaa otsikko.

  Näistä voi myös tulla ehdokkaita funktioiden abstraktioon, esimerkiksi function isLegalDrinkingAge(age) { return age >= 19 }. Ainoa asia on, että usein yrityksesi logiikka paljon mutkikkaampi kuin että, ja ei ehkä ole järkevää alkaa kirjoittaa kymmeniä toimintoja, joissa kussakin on 20-30 parametria. Jos esineisiin ja / tai funktioihin perustuvaa abstraktia abstraktiota ei ole, vakioihin turvautuminen on OK.

  Varoitus on, että jos työskentelet vero-osastolla, siitä tulee todella todella raskasta ja rehellisesti turhaa kirjoittaa AttachForm(FORM_CODE_FOR_SINGLE_TAXPAYER_FILING_JOINTLY_FOR_DEPRECIATION_ON_ARMPIT_HAIR). Et aio tehdä sitä t, olet menossa AttachForm("B-46"), koska jokainen kehittäjä, joka on koskaan työskennellyt tai työskentelee siellä, tulee tietämään, että ”B-46” on yhden veronmaksajan lomakekoodi arkistointi blaa blaa blaa – lomakekoodit ovat osa itse verkkotunnusta, ne eivät koskaan muutu, joten ne eivät ole oikeastaan maagisia numeroita.

  Joten sinun on käytettävä vakioita säästeliäästi liikelogiikassa; pohjimmiltaan sinun on ymmärrettävä, onko ”maaginen numero” todella maaginen numero vai onko se toimialueen tunnettu osa. Jos se on toimialue, niin et koodaa sitä, ellei siellä ole ”sa todella hyvät mahdollisuudet, että se muuttuu.

• Virhekoodit ja tilaliput

  Nämä ovat ei koskaan kunnossa kovakoodaamiseen, kuten kukaan huono paskiainen, johon on koskaan osunut Previous action failed due to error code 46, voi kertoa sinulle. Jos kielesi tukee sitä, sinun tulisi käyttää luettelointityyppiä. Muussa tapauksessa sinulla on yleensä koko tiedosto / moduuli täynnä vakioita, jotka määrittelevät tietyn virhetyypin kelvolliset arvot.

  Älä koskaan anna minun nähdä return 42 virheenkäsittelijässä, capiche? Ei tekosyitä.

Jättäin todennäköisesti pois useita skenaarioita, mutta mielestäni se kattaa suurimman osan niistä.

Joten, joo, se on joskus hyväksyttävää käytäntö kovaan koodiin. Älä vain ole laiska siitä; sen pitäisi olla tietoinen päätös eikä pelkästään vanha huolimaton koodi.

Kommentit

• Kiitos hyvästä erittelystä! – useimmat ihmiset eivät ’ ajattele kaikkia vaihtoehtoja, jotka lisääisin ” Ympäristön määritykset ” – mielestäni näitä tulisi välttää (ei kovakoodattuja), koska suurin osa tiedoista tulisi laittaa asetustiedostoon tai tietokantaan. Tämä seuraa periaatetta, jonka mukaan ” pidetään tiedot ja logiikka erillään ”, joka on MVC: n tai MVVM: n tukipilari. merkkijono TestServerVar = ” foo ”; merkkijono ProdServerVal = ” bar ”;

Tunnisteen antamiselle numerolle on useita syitä.

• Jos numero saattaa muuttua, sillä tulisi olla tunniste. NUMBER_OF_PLANETS on paljon helpompaa löytää kuin etsiä jokaista 9 esiintymää ja miettiä, pitäisikö se vaihtaa 8. (Huomaa, että käyttäjä näkee merkkijonot saattavat joutua muuttumaan, jos ohjelmistoa on koskaan käytettävä eri kielellä, ja se on vaikea ennustaa etukäteen.
• Jos numeroa on vaikea kirjoittaa millään tavalla. Pi: n kaltaisille vakioille on parempi antaa yksi suurin tarkkuuden määritelmä kuin kirjoittaa se uudelleen useisiin paikkoihin, mahdollisesti epätarkasti.
• Jos numero esiintyy eri paikoissa. Sinun ei tarvitse tarkastella 45: n kahta käyttöä vierekkäisissä funktioissa ja miettiä, tarkoittavatko ne samaa.
• Jos merkitys ei ole heti tunnistettavissa. On turvallista olettaa, että kaikki tietävät mitä 3.14159265 … on. Ei ole turvallista olettaa, että kaikki tunnistavat painovoiman vakion tai jopa pi / 2. (”Kaikki” riippuvat tässä ohjelmiston luonteesta. Järjestelmän ohjelmoijien voidaan odottaa tietävän Unix-lupabittien tai vastaavien oktaaliesityksen. Laivasto- / meriarkkitehtuuriohjelmistoissa tarkistamalla ehdotetun rungon Froude-numero ja nopeus katso, voisiko sen 1.1 tai uudempi olla täysin itsestään selvä kenellekään, jonka pitäisi työskennellä sen kanssa.)
• Jos asiayhteyttä ei voida tunnistaa . Kaikki tietävät, että tunnissa on 60 minuuttia, mutta kertominen tai jakaminen 60: llä voi olla epäselvä, jos ei ole välittömiä viitteitä siitä, että määrä on aika- tai nopeusarvo .

Tämä antaa meille kriteerit kovan koodauksen kirjaimille. Niiden tulisi olla muuttumattomia, ei vaikea kirjoittaa, esiintyä vain yhdessä paikassa tai kontekstissa, ja niiden merkitys on tunnistettavissa. Ei ole mitään järkeä. määritettäessä 0 esimerkiksi ARRAY_BEGINNING tai 1 ARRAY_INCREMENT.

Lisänä muihin vastauksiin. Käytä vakioita merkkijonoihin, kun mahdollista. Et tietenkään halua olla

const string server_var="server_var"; 

mutta sinun pitäisi olla

const string MySelectQuery="select * from mytable;"; 

(olettaen, että sinulla on todella kysely, josta haluat saada kaikki tulokset tietystä taulukosta, aina)

Muuta kuin muuta, käytä vakioita mihin tahansa muuhun lukuun kuin 0 (yleensä). 255-bittinen peite, älä käytä

const int 8th_bit=255; //or some other obscure naming scheme that equates to 255. 

käytä sen sijaan

const int AllowGlobalRead=255; 

Tietysti yhdessä vakioiden kanssa tiedetään, milloin käyttää laskijoita. Yllä oleva tapaus sopisi luultavasti yhteen.

Kommentit

• typedef enum {state_0 = 0, state_1 = 1, state_2 = 2, .. .} … Älä ’ älä naura, olen ’ nähnyt sen tekevän. Pistä sitä henkilöä pään ympärille märällä kalalla!
• @nopeasti tietysti ’ haluaisit jotain enemmän typedef enum {init_state=0, parse_state=1, evaluation_state=2, ... }
• THIS_NAMING_CONVENTION_IS_RECOMMENDED_FOR_CONSTANTS
• Merkkijonoille et halua ’ vain vakioita. Haluat laittaa kaikki käyttäjän näkyvät merkkijonot jonkinlaiseen resurssitiedostoon (yksityiskohdat riippuvat käyttöjärjestelmästäsi), jotta voit vaihtaa helposti toiselle kielelle.
• Saatat myös haluta kiinnittää liikelogiikkaan merkkijonot (kuten SQL-kyselyt) resurssitiedostossa jonkinlaisella salauksella tai hämärtymisellä. Tämä estää ” uteliaita ” käyttäjiä kääntämästä logiikkaasi (tai tietokantamalliasi).

Se riippuu siitä, mitä pidät kovakoodauksena. Jos yrität välttää kaikkia kovakoodattuja asioita, päädyt pehmokoodauksen alueelle ja luot järjestelmän, jota vain luoja voi hallita (ja jota lopullinen kovakoodi)

Paljon asioita on kovakoodattu kohtuullisissa puitteissa ja ne toimivat. Toisin sanoen ei ole mitään teknistä syytä, miksi minun ei pitäisi voida muuttaa C # -sovelluksen alkupistettä (staattinen void Main ), mutta kovakoodaus, joka ei aiheuta ongelmia kenellekään käyttäjälle (paitsi satunnaiselle SO-kysymykselle )

Käytän nyrkkisääntöä että kaiken, mikä voi ja muuttuu, vaikuttamatta koko järjestelmän tilaan, tulisi olla sekoitettavissa.

Joten, IMHO, on typerää olla koodaamatta asioita, jotka eivät koskaan muutu (pi, gravitaatiovakio, vakio matemaattisessa kaavassa – ajattele pallon määrää).

Lisäksi on typerää olla koodaamatta sellaisia asioita tai prosesseja, jotka vaikuttavat järjestelmääsi ja jotka edellyttävät joka tapauksessa ohjelmointia, . e. on hukkaan sallia käyttäjän lisätä dynaamisia kenttiä lomakkeeseen, jos jokin lisätty kenttä vaatii ylläpitokehittäjää menemään sisään ja kirjoittamaan jonkin skriptin, joka saa asian toimimaan. Lisäksi on typerää (ja olen nähnyt sen muutaman kerran yritysympäristöissä) luoda jonkin määritystyökalun, joten mitään ei ole kovakoodattu, mutta vain IT-osaston kehittäjät voivat käyttää sitä, ja se on vain helpompaa käyttää sitä kuin tehdä se Visual Studiossa.

Joten viimeinen asia, onko jokin asia koodattava, on kahden muuttujan funktio:

• muuttuuko arvo
• miten arvon muutos vaikuttaa järjestelmään

Onko koskaan hyvä idea koodata arvoja sovelluksiimme?

I kovakoodiarvot vain jos arvot on määritelty eritelmässä (spesifikaation viimeisessä julkaisussa), esim. HTTP-OK-vastaus on aina 200 (ellei se muutu RFC: ssä), joten näet (joissakin koodeissani) vakioita, kuten:

public static final int HTTP_OK = 200; 

Muutoin tallennan vakiot ominaisuustiedostoon.

Syy, miksi määritin tekniset tiedot, on se, että vakioiden muuttaminen spesifikaatioissa vaatii muutosten hallintaa, jossa sidosryhmät tarkistavat muutoksen ja hyväksyvät / hylkäävät sen. Se ei koskaan tapahdu yhdessä yössä, ja hyväksyntä kestää kuukausia / vuosia. Älä unohda, että monet kehittäjät käyttävät määrityksiä (esim. HTTP), joten sen muuttaminen tarkoittaa miljoonien järjestelmien rikkomista.

• jos arvo voi muuttua ja todellakin saattaa muuttua, koodaa se pehmeästi aina kun se on mahdollista, kunhan siihen liittyvä työ ei ylitä odotettua tuottoa. pehmeäkoodattu; noudata Jonathanin ohjeita (harvoissa tapauksissa)

Olen huomannut että milloin tahansa voit purkaa tietoja koodistasi, se parantaa jäljellä olevaa. Alat huomata uusia korjauksia ja parantaa koodisi kokonaisia osia.

Se on vain hyvä idea työskennellä vakioiden poistamiseksi, älä pidä sitä typeränä säännönä, ajattele sitä mahdollisuutena koodata parempi.

Suurin etu olisi tapa, jolla saatat löytää vastaavien vakioiden olevan ainoa ero koodiryhmissä – niiden abstraktio taulukkoina on auttanut minua pienentämään joitain tiedostoja 90% niiden koosta ja korjaamaan melko muutama kopio & liitä vikoja sillä välin.

En ole vielä nähnyt yksittäistä etua tietojen purkamatta jättämisestä.

Koodin äskettäin MySQL-funktion laskemaan etäisyyden oikein kahden lat / pitkän parin välillä. Et voi vain tehdä pythagorusta; pituuspiirit lähestyvät toisiaan, kun leveysaste kasvaa napoja kohti, joten siihen liittyy jonkinlainen karvainen trigeri. Pisteenä on, että olin melko revitty siitä, koodataanko maapallon sädettä edustava arvo maaleina.

Päädyin tekemään sen, vaikka tosiasia on, että lat / lng-linjat ovat paljon lähempänä toisiaan, esimerkiksi kuulla. Ja toimintoni ilmoittaisi huomattavasti vähemmän etäisyyksiä Jupiterin pisteiden välillä. Ajattelin, että kerroin verkkosivustolle, johon rakennuksen ulkopuolinen sijainti saadaan, on melko ohut.

Kommentit

• Kyllä, luultavasti, mutta mitä noin google.com/moon

Se riippuu siitä, onko kielesi käännetty. Jos sitä ei käännetä, se ei ole iso juttu, muokkaat vain lähdekoodia, vaikka se olisi hieman herkkä muille kuin ohjelmoijille.

Jos ohjelmoit käännetyllä kielellä, tämä ei selvästikään ole hyvä idea, koska jos muuttujat muuttuvat, sinun on käännettävä uudelleen, mikä on iso ajanhukkaa, jos haluat muuttaa tätä muuttujaa.

Sinun ei tarvitse tehdä liukusäädintä tai käyttöliittymää muuttujan dynaamiseksi muuttamiseksi, mutta vähiten mitä voisit tehdä, on tekstitiedosto.

Esimerkiksi minun ogre-projektissani käytän aina ConfigFile-luokka lataamaan muuttuja, jonka olen kirjoittanut config-tiedostoon.

Kaksi tilannetta, joissa vakiot ovat (ainakin mielestäni) kunnossa:

1. Vakiot, jotka eivät liity mihinkään muuhun; voit muuttaa näitä vakioita milloin tahansa ilman, että sinun tarvitsee muuttaa mitään muuta. Esimerkki: Ruudukon sarakkeen oletusleveys.

2. Ehdottomasti muuttumattomat, tarkat, ilmeiset vakiot, kuten ”päivien määrä viikossa”. days = weeks * 7 Korvaamalla 7 vakiona DAYS_PER_WEEK ei tuskin ole mitään arvoa.

Olen täysin samaa mieltä Jonathanin kanssa, mutta koska kaikissa säännöissä on poikkeuksia …

”Maaginen numero teknisissä tiedoissa: Maaginen numero koodissa”

toteaa periaatteessa, että kaikki maagiset numerot, jotka jäävät spesifikaatioon kohtuullisten yritysten jälkeen saada kuvaava konteksti heille, tulisi heijastaa sellaisenaan koodiin. Jos maagiset numerot jäävät koodiin, on pyrittävä eristämään ne ja yhdistämään ne selkeästi lähtöpisteeseensä.

Olen tehnyt muutaman liitäntäsopimuksen, jossa on tarpeen täyttää viestit kartoitetuilla arvoilla tietokannasta. Useimmissa tapauksissa kartoitus on melko suoraviivaista ja sopisi Jonathanin yleisiin opaslinjoihin, mutta olen havainnut tapauksia, joissa kohdeviestin rakenne oli yksinkertaisesti kauhea.Yli 80% arvoista, jotka jouduttiin siirtämään rakenteessa, olivat vakioita, jotka pakotettiin määrittelemään kaukainen järjestelmä. tämä yhdistettynä siihen tosiseikkaan, että sanomarakenne oli valtava, sai aikaan, että PALJON tällaisia vakioita oli täytettävä. Useimmissa tapauksissa ne eivät antaneet merkitystä tai syytä, vaan sanoivat ”laita M tänne” tai ”laita 4.10.53.10100.889450.4452 tänne”. En myöskään yrittänyt laittaa kommenttia niiden kaikkien viereen, se olisi tehnyt tuloksena olevan koodin lukukelvottomaksi. Varmistin kuitenkin, että koodiosat, joissa nämä maagiset arvot näkyvät, on eristetty asianmukaisesti ja että niiden säilöt (luokat, paketit) on nimetty asianmukaisesti osoittamaan suoraan niitä noudattavaan määrittelyyn.

Siitä huolimatta kun ajattelet se … siinä on melkein kaikki sen tekeminen ilmeiseksi …

Jos koodaat uudelleen maan painovoiman vakiota, kukaan ei tule hoitamaan sitä. Jos koodaat välityspalvelimen IP-osoitteen kovalla koodilla, sinulla on ongelmia.

Kommentit

• Saatat tarvita tarkempaa tietoa maapallolle ’ s painovoima, joten sen kova koodaaminen useita kertoja saattaa johtaa ongelmiin.
• Peter Noone? Hermanista ’ Hermits ?
• Maapallon painovoimakiihtyvyys on melkein 9,81 m / s ^ 2 useimmilla leveysasteilla ja korkeuksilla (tietysti, jos ’ etsit öljyä maan alla, tai ampumalla ICBM: itä pohjoisnavan yli, painovoiman vaihtelun tunteminen on erittäin tärkeää paljon desimaalipilkkuihin saakka), kun muiden planeettojen painovoimakiihtyvyys on eri numero, mutta tietojeni mukaan painovoiman vakio on vakio maailmankaikkeuden ympärillä. Paljon fysiikkaa on muutettava, jos g olisi muuttuvaa.

Enimmäkseen ei, mutta mielestäni on syytä huomata, että olet wi Minulla on eniten ongelmia, kun aloitat kovakoodatun arvon kopioinnin. Jos et kopioi sitä (esim. Käytä sitä vain kerran luokan toteutuksessa), vakion käyttämättä jättäminen saattaa olla kunnossa.