framtida jobb?

Men du bestrider inte mitt påstende ändå att du inte är en av dessa få personner?


I viss mening, ja det är vad man eftersträvar. Det finns ful kod, vanlig kod och sedan vacker kod som man lär sig mest från. Revolutionerande idéer från de som är bäst på det de gör. Design-mönster som ger en "aha! smart!" känsla.


Rent är naturligtvis subjektivt, men i detta fall syftade jag på "rent" med avseende på hur verbalt någonting är. I.e. likvärdigt med att ha "elementCount" istället för "stNumberOfElementsInTable".

Roligt att du tar upp assemblerkodare föresten. Måste tyvärr upplysa dig om att OO-programmering med C++ använder sig (bör använda sig) av helt andra stilar än C/assembler. För att citera Wikipedia som citerade Bjarne:

"No I don't recommend 'Hungarian'. I regard 'Hungarian' (embedding an abbreviated version of a type in a variable name) a technique that can be useful in untyped languages, but is completely unsuitable for a language that supports generic programming and object-oriented programming—both of which emphasize selection of operations based on the type an arguments (known to the language or to the run-time support). In this case, 'building the type of an object into names' simply complicates and minimizes abstraction."


Du har fortfarande inte kommenterat varför det kan komma sig att två gigantiska C projekt med mycket större orsaker att använda sig av ungersk-notation inte använder det. Vi snackar inte om vanliga C++ projekt utan fall där fundemental funktionalitet (läs: interaktion med hårdvara) skiljer sig beroende på om någonting är en "int" eller en "long long".


Tja... min editor färglägger medlemsvariabler i en annan färg än vanliga lokala. Med eller utan "m_" ser jag ändå skillnaden.

Intressant nog använder jag själv ändå scope-prefixer, en vana som snappades upp efter att ha kodat multitrådat. Jag betraktar det mer att tillhöra Apps formen eftersom globala/medlemsvariabler i många fall måste behandlas med större omsorg där (i.e. någon form av "Varning!! Se upp när du accessar variabeln! Överväg lås!").


http://pastebin.com/f76b9f7e2

http://pastebin.com/d766ae987

Ökar ungersk-notation läsbarheten av koden? Nej, den drar bort fokus från det viktiga. Ta "pcullBlock" som ett exempel. Ja, man ser att det är en pekare till en konstant unsigned long long men har man bara ett bättre minne än en guldfisk så kommer man ändå ihåg att "tja... vi arbetar ju med 64-bitars block här".

Design-dokumentet ligger externt i form av en word-fil som förklarar varför man gör som man gör där inne. Kommentarer om hur crc32cx2_sse42 används är överflödit. Indata parametrarna har väldigt standariserad form. Man behöver inte ens gissa till sig att "man skickar en buffert och en längd och får sedan en hash".

ps. Glöm inte att kommentera varför C-projekt som Linux-kärnan och FreeBSD uppenbarligen klarar sig finfint utan ungersk-notation. Glöm inte heller att kommentera varför modernare språk och bibliotek som C# och Java inte heller använder sig av det.

Ah, du lyckades smita in en post före mig.


Instämmer där! Det absolut viktigaste är självklart att i slutändan följa samma stil som resten av projektet, om någon sådan stil redan är definerad.

"If you are in Rome, do as Romans do."

Därmed accepterar jag att man kan använda sig av "System" ungersk-notation om man direkt arbetar mot Windows gamla API, även om jag personligen tycker att det är en "ful" stil.

Jo, har en del lyckade projekt bakom mig

Jag förstår kanske att du mest tänker på att lära dig då det är lätt att märke att du precis kommer från studier (eller möjligen studerar nu).
Det är inte det jag menar, det min argumentation går ut på är att man skall ta sig i mål med ett projekt och då att folk skall kunna vara lika effektiva i slutet som i början.

"stNumberOfElementsInTable" är inte ett bra ord för jag kan inte se typen "st" ??? och varför lägger du in fler ord där när du jämför med "elementCount" ?
Varför inte bara "uElementCount" ?

Det är du som tar upp ungersk notation, den är enligt mig inte bra för där kan man använda "egna" förkortningar. en förkortning måste programmeraren direkt komma ihåg.
Regler för hur man kodar måste vara så att programmeraren skall kunna räkna ut vad som står där endast genom att läsa raden utan att titta på annat. det skall vara så få och enkla samt tydliga regler som möjligt

39 rader kod?
Öka till 39000 rader kod så får du se, eller varför inte 390 000. Så fort du inte kan se deklarationen och hur variabeln används på skärmen samtidigt så börjar typen som prefix att visa sina fördelar. Då måste nämligen programmeraren börja koncentrera sig för att minnas om han inte direkt kan se på variabeln vad det är.

annan variant
http://pastebin.com/f2a92e81d

Du kan där ta ut varje rad separat och räkna ut vad varje del är under förutsättning att du fått en kort introduktion om hur standardtyperna skall förkortas. Behovet av att hoppa omkring i koden för att se finns inte, du behöver inte föra musen över för att låta editorn berätta för dig. Du kan bara läsa raden rakt av.


Problemet vid denna typ av diskussion är att man använder dåliga exempel för att visa, förkortningar på typer är enligt mig extremt illa då varje förkortning måste kommas ihåg och tas reda på. Endast standartyper bör förkortas och då på ett lätt sätt. annars skriver man ut hela objektets namn som prefix. Är objektets namn långt så går det och förkorta, en regel som fungerat mycket bra då är att alltid förkorta varje ord i objektet med stor bokstav. Inte maximal tydlighet men programmeraren kan direkt räkna ut att det dels är en förkortning och förstå förkortningen genom att bara lärt sig en regel.
CThisIsALongObjectName TIALON;

Japp, jag studerar just nu men arbetar extra vid sidan om på ett företag som skriver extremt stora tidskritiska (bank-)system.

Även om jag högst troligen är yngre än dig så har jag ändå programmerat C++ i 13 år där minst 5 av de huvudsakligen har varit tävlingsprogrammering (läs: så mycket "tidskritiskt" som det kan gå) med resultat som endast fyra eller fem andra personner någonsin har haft bättre av här i Sverige.

Hurvidda det är tillräckligt eller ej med erfarenhet låter jag vara osagt. Men programmerare som inte längre är villiga att fortsätta att lära sig är ofta väldigt dåliga programmerare också (men med ett stort ego).


Det var ett exempel på varför verbalt inte alltid är bra. Inte direkt att "titta här vad förvirrande ungersk-notation är".

"System" ungersk-notation sätter fokus på vad för typ en variabel är.

OO-paradigmen försöker istället sätta fokus på "vad" en variabel symboliserar. I detta fall är det "antalet element". Hur man räknar antalet element betraktas som irrelevant. Om man får för sig att ändra om typen till BigInteger så ska det fungera bra också.


Jag skulle vilja föreslå att du läser på om vad ungersk-notation syftar på. Jag skulle också vilja föreslå att du läser på om skillnaden mellan "System" och "Apps" formen (även om det till en viss del överlappar varandra). Det du beskriver (t.ex. med "u") är typiskt "System" formen av ungersk-notation.

Linux kärnan använder sig inte av "u", "p" eller ens "m_".


"size_t bytesLeft = length - blockCount * 8;"

Du tar totala längden, drar bort antalet block där varje block har längden 8. Resultatet är antalet bytes som är kvar.

Vad spelar det för roll om length eller blockCount är av typen size_t, int, unsigned int eller någonting annat?

En gammal assemblerprogrammerare svarar nog "all skillnad i världen".
En programmare som strikt följer OO-design svarar nog "inte mycket alls; vi försöker trots allt abstrahera bort skillnaderna".


Du måste ha ett kaosaktig projekt som låter kod från så pass stora områden interaktera med varandra genom variabler.

En funktion bör rymmas på en skärmbild. Empiriska studier visar på att antalet defekter ökar kraftigt om man bryter mot den "regeln". Lokala variabler ser man då direkt typen på utan att "söka runt".

En klass bör endast ha upp till c:a 8 medlemsvariabler. Empiriska studier visar på att om antalet ökar över det så ökar också antalet defekter (finns självklart vanliga undantag). Medlemsvariablerna är per OO-design sluten i en "svart" låda och endast kan nås av klassen själv.

Det spelar därmed ingen roll att projektet är 39, 390, 3900, 3 900, 39 000 eller 390 000 rader. Variabeln "lever" här endast för 39 rader med kod (egentligen ännu mindre eftersom pcullBlock's effektiva scope är 6 rader (där 2 är "{" och "}")!).

Återigen kan vi använda oss av Linux eller FreeBSD som exempel här. Jag vet inte om detsamma gäller för dig, men jag själv har inga som helst problem att sätta mig in i sådan kod även om de inte har extra "ungersk-brus".


En bra programmerare har en "minnesstack" som sträcker sig längre än 1 rad. I ditt fall måste man ändå kolla upp om alla "u" variabler är "unsigned int" eller "size_t" (d.v.s. "unsigned int"/"unsigned long long" beroende på arkitektur).

I värsta fall kommer det en ny person och gissar på att det är "unsigned int" som du menar och därmed antar att den tar upp 4 bytes. Och *smack* så kanske introducerar han en defekt när programmet senare portas till ett 64-bitars system.

För att citera "Linux kernel coding style":

"Encoding the type of a function into the name (so-called Hungarian notation) is brain damaged - the compiler knows the types anyway and can check those, and it only confuses the programmer. No wonder MicroSoft makes buggy programs."

C - J hade annars en bra post också.

då begriper jag inte varför du har så svårt och sätta dig in hur andra menar eller din känslighet för kritik.
ta bara det där med hash, något vilken kunnig programmerare som helst vet om.
Samt, om du hållt på så länge och inte har egen kod och visa upp?
vad jag känner till så är banksektorn inte direkt kända för bra kod heller

Här är ett exempel på det jag menar ovan, det är du som dragit upp ungersk notation, jag har nämnt tidigare att jag kör något liknande men att jag inte tycker ungersk notation är riktigt bra, samma med apps och så vidare.

Vad jag sagt så är det viktigt att man vet typen, är det omöjligt och visa typen så skall man ha så få och enkla regler som möjligt för att programmeraren snabbt skall förstå ändå.

Du har själv visat kod eller skrivit någon liknande "lowerCamelCase", det är förmodligen den absolut sämsta kodstil som man kan välja (även om många valt det..). orsaken är att det omöjligör många andra regler för att göra koden mer lättläst och tillför i princip inget alls.

Och där har du förmodligen en av de största anledningarna till att linux världen varit så seg och komma igång. Ofta är det så att programmerare tar efter kod de sett tidigare. När det blir större projekt så är sådant här fruktansvärt viktigt. Microsoft har vad jag sett (av den koden man kan se) haft generellt en klart högre nivå på läsbarhet och kodar bättre (de verkar dock ha tappat senaste tiden, möjlige suger google mm upp de bästa resurserna).
Hade de kodat bättre inom open sourcevärlden, alltså tänkt på att koden skall vara lätt och hantera så hade de kommit längre. det finns gott om duktiga personer, men f*n vad illa många kodar

Bara för att ge dig en tankenöt. Du har nu spridit denna diskussion till två trådar varav en gick upp till 100+ poster och denna börjar att närma sig en sådan nivå också. Vem är det som har fått i princip alla att gå emot sig eftersom dennes argument skiljer sig så starkt från vad man kan anse vara vanliga erfarenheter av folk i branchen?


Var vänlig och citera mig där jag explicit har fel angående hashar, med uppbackning av benchmarks, forskningsrapporter eller andra oberoende källor på att jag har haft fel? Eller är du så arrogant att tro att din magkänsla övervinner allt?


En stor del av koden som jag har skrivit är under NDA. Det är denna del som jag anser vara "kodstil i stil med vad som är vanligt på företagen".

En annan stor del täcks av algoritm-kod för tävlingar och som inte är relaterad till detta ämne, som medvetet prioriterar "snabbt att skriva av från papper" (läs: minimera antalet tecken) och prestanda före läsförståelse.

Du måste i princip redan ha mycket djupa kunskaper inom ämnet innan du kan snappa upp vad koden egentligen gör. OO-design existerar inte. Det är i de fallen så extremt att man till och med typedefar "pair<int, int>" till "pii" för att kapa av några sekunders skrivtid (och i någon konstig bemärkelse faktiskt också ökar läsförståelse av koden under de timmar koden "behövs").


Jag tror inte att du har haft någon som helst kontakt med back-end systemen där och därmed realistiskt inte kan uttala dig om det överhuvudtaget.

Vi pratar inte om att koda GUI-t som används i kassan utan bearbetning av transkationerna själva. Det är kod som dagligen hanterar massiva mängder av data och som helt enkelt inte får vara fel. I stil med mjukvara för Nasas rymdsonder som måste nå noll defekter på en kodbas i storleksordningen "en miljon rader". Det är mycket högre krav där än vad som existerar för vanliga applikationer.


Kalla det vad du vill, men att direkt baka in typen i variabelnamnet är per definition ungersk-notation. Det är den korrekta termen. Liknande med att "jag öppnar socketen när objektet skapas och stänger den när objektet destrukteras" följer RAII, och C#/.NET's garbage collector är inte referensräknande. Att "plussa ihop två tal" är att addera, och ingenting annat.

För att göra sig förstådd på nätet (eller i allmänhet) så är det viktigt att man inte skapar sig sina egna betydelser utifrån ord som redan accepteras som att ha någon annan betydelse.


Smaksak där (många C-programmerare föredrar "underscore" som separator istället).

litenKamel för variabler och funktionsnamn gör så att man undviker kollisioner med StorKamel för klasser och ENORM_KAMEL för macron, och kan i din klassiska anda direkt se vad någonting är för någonting.

Ta t.ex. fallet med "buffer".

"Buffer buffer;" versus "buffer ...?...;"

Om något man ska klaga på (vilket egentligen är rätt så löjligt att klaga på ändå) är att du använder dig av StorKamel för funktionsnamn också. Det går därmed inte att direkt skilja mellan att skapa ett nytt objekt eller att anropa en funktion (antingen statisk sådan i vanliga klasser eller om det ligger in ett namespace).

D.v.s. något i stil med: "HashMap::Hash(key);" och "HashMap::Hash(key);"

Vad är vad?

Nu säger jag inte att StorKamel för funktionsnamn rakt av är "fel", men det har sina konflikter också. I slutändan är det en fråga om tycke och smak här (alternativt "religion").

I övrigt, var är dessa andra "många andra regler" som omöjliggörs? Eller har vi en av dina vanliga överdrifter här igen?


Du måste skämta? Linux... seg?

Linux har sprungit, i termer om popularitet, om *nix-projekt som härstammar från mycket äldre tider, som t.ex. BSD och Solaris. Den har ätit upp en del av Microsoft-kakan som jag för fem år sedan knappast skulle tro vara möjligt.


Du måste skämta igen?

Microsoft själva gör periodiskt mycket stora omskrivningar av sin kärna eftersom de gamla har varit "ihoplappade" alltför många gånger. Med Windows 8/Midori planeras en total omskrivning från grunden av kärnan.

Och på toppen av isberget...

Den legendariska Dave Cutler, arkitekten bakom Windows NT, fick syn på Microsofts (på den tiden) förälskelse i ungersk-notation och bannlyste stilen från NT kod-trädet. Så även om API-t har parametrar med ungersk-notation (eftersom det äldre Windows 3.x/9x hade det) så verkar det inte gälla "bakom kulliserna".


Därför letar du dig mot BSD folket... men vänta nu? FreeBSD använder inte -heller- ungersk-notation!

haha, är det bättre då att aldrig veta?
argumenten de har som förespråkar "skriv variabler hur du vill" är inte direkt briljanta när de förklarar fördelar respektive nackdelar

Som jag tidigare ha nämnt, antingen behöver han per OO anda inte veta alls och det därmed endast kan betraktas som "brus" (normala fallet).

Eller så behöver han verkligen veta det (detta fall) och kan lätt unna sig de 0,5 till 1 sekunder det tar att flytta musen över variabelnamnet eller att klicka på variabeln och därmed få reda på exakt vilken typ det är.

Sekunder som sparas in på att han inte behöver klia sig på huvudet och försöka att parsa vad "ppcpcull" betyder på andra ställen. Eller mer realistiskt exempel där han försöker att avgöra om "pullForce" är en "unsigned long long*" eller ett "Pull"-objekt. Eller i ditt fall, att försöka klura ut om det är en "size_t", "unsigned int" eller något annat.

Eller sekunder som han sparar när han en gång för alla bestämmer sig: "Nej, nu ska vi använda oss av unsigned istället för signed!" (men oops... vi har ju sjuttioelva variabler som nu måste byta från att heta "cost" och "count" till "uCost" och "uCount"!).


Lösa påståenden om att någonting är bättre utan att lägga fram källor som nickar instämmande (när det å andra sidan finns många stora källor som tyder på att motsatt effekt ofta nås) är alltså briljanta argument? Att slänga in ord som "mycket", "extremt" och "lätt" gör inte någonting mer trovärdigt.

Nackdelarna med denna stil har nu presenterats i flertal långa poster här, med citat från erkänt framstående programmare om varför det oftast är dåligt och ej heller nödvändigt i ett modernt språk.

Fördelarna har attackerats med hjälp av argument som att starkt typade språk har en kompilator som skyddar en, att man har rört sig mot att abstrahera så mycket som möjligt istället, att en IDE som Visual Studio har blivit kraftig nog att göra stilen överflödigt, o.s.v.

Stilen har blivit attackerat på hemmaplan med exempel på de största projekten som historiskt har alla orsaker att använda sig av denna stil men som av någon anledning ändå inte gör det. Slutsatsen man då bör kunna dra är att stilen kanske anses ställa till mer besvär än vad det är värt.

För *nix-utveckling så pratar vi dessutom om folk som vanlig inte använder sig av IDE-n av Visual Studio's kaliber (jag får nog sota för det påstående när någon Emacs/Vim guru dyker upp ) men som ändå väljer att använda sig av ungersk-notation-fri stil.

Alla här är inte lika arroganta och slänger "mitt sätt är det enda som duger" i ansiktet på andra, utan är villig att acceptera att "vi kan endast säga vad för- och nackdelarna är, sedan är det upp till dig själv att välja, och om en stil redan existerar på projektet du jobbar med så bör du använda dig av den".

Det kan men även om du har typen som prefix, att ha typen som prefix är en hjälp. Det går lättare och läsa kod för normalt har en funktion mer än en variabel
Har den tio olika så börjar det bli lite svårt och komma ihåg, är det dessutom så att man hoppar omkring lite i funktioner, ja du kanske kan räkna ut (eller fick jag för höga tankar om dig nu?)

Har du hört det där att en del lätt brukar glömma av att radera pekare? vad kan vara pekare tro... när man skriver variabler som man vill

Det är du som är för känslig för kritik, jag kan nog hålla igång dig ett bra tag till

har vart lite offtopic nu rätt länge va?