Min tanke har var ett tag att dela ett stycka data precis som jag haft nytta av delat data. Nu efter att ha tvekat på det "ganska länge" har jag kommit fram till att jag tvekat ganska korrekt och jag tänker inte dela något unikt data förutom längre fram vad diverse copyright åtagande-fodrar.
Likväl tror jag - hoppas i alla fall - att ett karma värde ligger i att dela något minst lika värdefullt men mindre relativt power-förändrande relativt andra tänkbara aktörer ej allt för långt ifrån intresse. Därför tänkte jag mig att hellre än att dela statistika relationsmått eller liknande mellan koncept ge ett stycke oerhört värdefull förståelse relaterat programmering som i varje steg där jag vågat accepterat det fortsatt addera värde: vikten av standardisering. Jag kallar denna form av potent värdefulla delning som når fler integrerande till ett så pass mycket större värde för Sharing value the Good way eller i ett likartat men svenskt benämnt koncept Balanserat generös och små-snål (erkännande min generösa såväl som snåla attityd och delande tycker jag egentligen mer totalt i områden jag bryr mig mindre i och är ganska säker på kan skapa minst lika stort värde för andra om vi antar att motivation är drivande likartat för resp. område hos läsare - och också om en del läsare kan tycka annorlunda betvivlar jag att de hör till annat än just den minoritet jag ej vill dela data med).
Normalt om vi betänker ett systemutvecklingsprojekt donerar var och en huvudsakligen med egen kod ändå relativt begränsad i omfång. Här snarare för mig trots en person med möjlighet till egna preferenser och bias att få en viss förenklad förståelse har storleks-omfånget på projektet varit större än vad som normalt förväntad av en individ - därav trots att jag gjort koden förutom insatsvaror m.m. själv har jag av och till och regelbundet lidit av motsvarande den problematik vi i systemutvecklingsprojekten för när en annan person tvingas ta över någon annans kod.
Det normala sättet att hantera detta problem är att "kommentera" koden vilken vanligen inkluderar en beskrivning i en abstraktion ovanför själva koden. Denna lösning är min erfarenhet är vettig och förslag på annat koncept här är mer kompletterande nyttan av den.
Vad vi här avser är snarast problematiken som kommer från in-repeterade vanor ytterst kodnära vilka utan standardisering både per individ resp. i projekt kan variera radikalt. När man tar upp befintlig kod och dessa förändrats - och ännu värre förändrats till att bibehålla något inrepeterat i benämning men vars syfte och mening förändrats - så kommer onödiga defekter såväl som mindre effektiv tidskostnad för att uppleva sig förstå tiden nog för att förändra den.
Hur man gör sådan standardisering har jag ej någon metodik passande projekt med flera för att istället låtit det hela växande fram (i relativt stora delar också styrt av att jag önskar kunna porta min Perl kod till C utan onödigt arbete) men några ex. från gällande mig illustrerar åtminstone vad jag avser (d.v.s. resp. standardisering kan i sig vara sämre än alternativ i andra situationer):
- Alla loopar görs med while.
- Först räknare i loop ä i, nästa och nästlad k, därefter cc och efter det antingen counter eller cc räknad.
- Tagande ut förekomst i hash-tabell först keys, dess nycklar gg, dess nycklar hh
Särskilt i sista exemplet ser vi att standardiseringen tappar en del kod specifik meningsfullhet man kanske kan tycka är funktionellt kring sådant här i variabel namnen. Typiskt rörande särskilt sista fallet finns dock föga riktad logik rörande refererande själva nycklarna i hash-tabeller och vandrande djupare ner i dem och det ev. mer komplexa i logik kan vi lösa genom att tilldela någon variabel vad vi för loop-steget avser.
Mängden tid sådan standardisering avser är direkt förvånande substanstiell. Jag kan dock tänka mig att det varierar något med personlighet huruvida detta ger större eller mindre värde ex. jämfört med logik-kommentering (antagande att vi utesluter antingen den ena eller den andra metoden).
Jag vinner rent av viss tid på att standardisera benämning av status-styrande variabler i samband med data-import. Nyligen standardiserade jag de två parallella räknare som styr när skärm-utskrift sker gående igenom någon mängd data för import tll c1 resp. c2 och i och med de använder jag aldrig den benämningen i övrigt för något eller benämner samma syfte hos variabler på annat sätt. Ex. väldigt (extremt väldigt faktiskt) typiskt för c1 och c2:
while ( my $cline = $fp -> getline() )
{
[...]
if ( $c1 > 50000 )
{
print $c2 . "\t" . $cline . "\n";
$c1 = 0;
}
$c1++;
$c2++;
}
Kanske inte lika konceptuellt resonerande och in-group förklarande elegant som design patterns m.m. men likväl mycket effektivt från min erfarenhet när mängden kod vandrat iväg i bredd och djup mer än vanligt förväntat oerhört besparande i tid.
Man ska komma ihåg att för en hel del i logik väldigt komplexa funktioner men med ett tämligen vanligt övergripande syfte förekommer det bl.a. inte alltid annat än ett fåtal variabler vars syfte och funktion inte motsvarar vad som direkt framgår i deras benämning.
