C++ och dess framtid att programmera minnessäkert - Hur går utvecklingen?

Permalänk
Medlem
Skrivet av klk:

Ja skrev snabbt och normalt för "is_ready" logik är att det är en hel del annat så poängen var att ha en klass/objekt. För den exempelkod du använder för att visa på ditt är inte normal kod och det är nära nog det enklaste du behöver ta till för att visa att HN inte spelar någon roll.

Man väljer inte hur kod skriv för enklaste möjliga exempel, man väljer hur kod skrivs för det mest avancerade. Det enklaste kan skrivas hur som helst, man fattar ändå

if (is_ready) { work(); }

Du undviker som vanligt frågan och svarar på något helt annat... VARFÖR MÅSTE JAG VETA OM is_ready ÄR EN DOUBLE ELLER INT?

Här är ett exempel från mitt kodprojekt(Rust denna gången), vad är det som inte är normalt?

if schedule.is_ready(task) { ... }

Vad returnerar metoden is_ready(), är det relevant för dig som läsare? Den mellanlagras in ens i en variabel, hur skulle du någonsin förstå den koden?

Permalänk
Medlem
Skrivet av klk:

if(is_ready){
work();
}

eller

if(bIsReady) {
work();
}
[/code]

Logiken i vad som händer är ju precis lika begriplig i bägge varianterna.
Den undre är dock mer svårläst, med ett "stökigare" variabelnamn, där det vid första anblicken (och med de flesta fonter) inte är så uppenbart om det står "bIsReady" eller "blsReady".
Om man är väldigt van vid just den notationen så kanske man tycker den undre är snabbare att läsa, men det är isåfall inte för att den i sig är bättre på något sätt, utan bara för att man är så fast i just den notationen att allting annat blir onödigt svårt att läsa.

Permalänk
Medlem
Skrivet av Erik_T:

Logiken i vad som händer är ju precis lika begriplig i bägge varianterna.
Den undre är dock mer svårläst, med ett "stökigare" variabelnamn, där det vid första anblicken (och med de flesta fonter) inte är så uppenbart om det står "bIsReady" eller "blsReady".
Om man är väldigt van vid just den notationen så kanske man tycker den undre är snabbare att läsa, men det är isåfall inte för att den i sig är bättre på något sätt, utan bara för att man är så fast i just den notationen att allting annat blir onödigt svårt att läsa.

Ja, i sådan här lätt kod spelar syntaxen/stilen ingen roll alls. Fungerar till och med med enbokstavsvariabler
Stil väljs inte efter lätt kod, det är svår kod som stilen behöver anpassa sig efter

Men som är en av HNs styrka, vad man kan skippa. Öppnas en fil med 5000 rader kod, hur hittar man snabbast i den filen?

Eller som ditt andra svar min frågeställning om 32 variabler att det behöver refaktoreras. Ja 32 variabler samt dessutom svår kod i en metod är ingen höjdare. Men det tar tid att skriva om och kod som lever (funktionalitet kommer ändras), den bli mycket mer lättjobbad med HN
Dålig kod blir hanterbar

Det går till och med att skriva metoder där en enda metod har 5 000 rader (har fått ta över sådan kod) och den går att jobba med.

Permalänk
Medlem
Skrivet av klk:

Ja, i sådan här lätt kod spelar syntaxen/stilen ingen roll alls. Fungerar till och med med enbokstavsvariabler
Men stil väljs inte efter lätt kod, det är svår kod som stilen behöver anpassa sig efter

Men som är en av HNs styrka, vad man kan skippa. Öppnas en fil med 5000 rader kod, hur hittar man snabbast i den filen?

Eller som ditt andra svar min frågeställning om 32 variabler att det behöver refaktoreras. Ja 32 variabler samt dessutom svår kod i en metod är ingen höjdare. Men det tar tid att skriva om och kod som lever (funktionalitet kommer ändras), den bli mycket mer lättjobbad med HN
Dålig kod blir hanterbar

Det går till och med att skriva metoder där en enda metod har 5 000 rader (har fått ta över sådan kod) och den går att jobba med.

Hur klarar sig dom största projekten på Github utan HN? Hur har jag klarat mig utan HN under hela min karriär?

Vill du veta svaret? HN behövs inte, vi alla fungerar olika... Om du behöver den extra hjälpmedlet som HN ger dig så fine kör HN men det ger inte mig något och ser mest kladdig ut och ett projekt som skalas upp över tid står/faller inte pga HN.

Kan vi gå tillbaka till testning och @klk beskriver hur du testar kod?

Permalänk
Medlem
Skrivet av orp:

Vad returnerar metoden is_ready(), är det relevant för dig som läsare? Den mellanlagras in ens i en variabel, hur skulle du någonsin förstå den koden?

De exempel du använder för att bevisa din ståndpunkt är meningslösa för vem som helst kan klara av den typen av kod hur den än skrivs. Hade kod varit så enkel hade små barn kunnat programmera

Permalänk
Medlem
Skrivet av orp:

Hur klarar sig dom största projekten på Github utan HN? Hur har jag klarat mig utan HN under hela min karriär?

HN fungerar inte i open source project. Mycket svårt att få andra att delta i projekt, extremt få projekt har många deltagare men om de lyckas brukar det vara en hel del och då är ofta koden separerad så bra att det är lätt att jobba med olika delar.

Som jag skrev tidigare så bestäms stilen av HN av delar som är naturliga, förkortningar måste vara självklara. Den här typen av regel kräver ofta att de som deltar i koden får en introduktion, eftersom den tröskeln finns går det inte att ha HN i open source project

HN lämpar sig nästan enbart i små team med vana utvecklare som skall ha mycket hög effektivitet eller i C projekt, där fungerar det med större team (eftersom C kodare har mycket bra koll på hårdvara)

Permalänk
Medlem
Skrivet av orp:

Kan vi gå tillbaka till testning och @klk beskriver hur du testar kod?

Försöker att bygga så mycket som möjligt på kod som återanvänds, den behöver inte testas.

Den lilla del som tillhör domänlagret (användardomänen), om det går lägger jag på skript (ofta LUA), i mitt lilla hobby projekt finns faktiskt en "expression" parser och kanske använder den så får jag den testad med.

Det skulle kunna se som att det finns uttryck i en textfil, skapar ett test som läser av varje rad och kör uttrycken och granskar resultatet. Inte gjort än men kan mycket väl tänka mig att det blir så.

Försöker undvika allt som innebär extra kod (extra kod = mer coupling = tar tid)

Permalänk
Medlem
Skrivet av klk:

De exempel du använder för att bevisa din ståndpunkt är meningslösa för vem som helst kan klara av den typen av kod hur den än skrivs. Hade kod varit så enkel hade små barn kunnat programmera

Nej det är dom inte, du bara inte en vettig comeback även om det inte brukar hindra dig.

Skrivet av klk:

HN fungerar inte i open source project.

Detta tror jag inte det minsta på. Varför kör du HN i ditt open source projekt? De lever än en gång inte som du lär.

Vad jag vet så har Github varken community guidelines mot HN eller några systematiska kontroller över det.

Skrivet av klk:

Mycket svårt att få andra att delta i projekt, extremt få projekt har många deltagare men om de lyckas brukar det vara en hel del och då är ofta koden separerad så bra att det är lätt att jobba med olika delar.

Det är för att folk inte tycker om det. Varför lägger du inte till radnumret för vart variabeln är deklarerad i variabelnamnet, då får du ju ännu mer info om variabeln och vet ju exakt vart den är deklarerad om du skulle behöva ändra det? Varför drar du linjen vid typ-info?

Du har många påhittade begränsningar som du trivs som HN, inbillningar om andra programmeringsspråk, att val av programmeringsspråk skulle säga något om utvecklaren osv. Det är så ironiskt hur du sa ett problem med många utvecklare är att dom inte tänker fritt samtidigt som du har varit fastlåst i ditt tänkande sedan millennieskiftet och allt som bryter mot din världsbild är objektivt fel eller dåligt.

Skrivet av klk:

Som jag skrev tidigare så bestäms stilen av HN av delar som är naturliga, förkortningar måste vara självklara.

Möjligen naturligt för dig men definitivt inte för mig.

Skrivet av klk:

HN lämpar sig nästan enbart i små team med vana utvecklare som skall ha mycket hög effektivitet eller i C projekt, där fungerar det med större team (eftersom C kodare har mycket bra koll på hårdvara)

Nu hittar du på igen. Jag har aldrig stött på ett projekt med HN och jag kodar framförallt C för embedded.

Permalänk
Medlem
Skrivet av orp:

Nej det är dom inte, du bara inte en vettig comeback även om det inte brukar hindra dig.

Tycker jag nog inte, försökte visa med kod och klistrar in den igen, hur hanterar du denna typ av funktionalitet (säg till om du vill ha andra exempel). Vill man ha önskad funktionalitet är det ibland svårt att undvika sådant här så vet du hur jag skall lösa det är jag tacksam för hjälp

/** --------------------------------------------------------------------------- * @brief Updates the pattern list for files in the cache using multithreading. * * This method processes a list of patterns and applies them to the files stored in the cache. * It generates a list of lines in each file where the patterns are found and stores the results * in the "file-linelist" cache table. The method uses multithreading to process files in parallel. * * @param vectorPattern A vector of strings representing the patterns to search for. * The vector must not be empty and can contain a maximum of 64 patterns. * @param argumentsList Arguments for pattern processing (e.g., segment specification, max lines) * @param iThreadCount Number of threads to use (0 = auto-detect) * @return A pair containing: * - `bool`: `true` if the operation was successful, `false` otherwise. * - `std::string`: An empty string on success, or an error message on failure. * * @pre The `vectorPattern` must not be empty and must contain fewer than 64 patterns. * @post The "file-linelist" cache table is updated with the lines where the patterns are found. * * @note COMMAND_ListLinesWithPattern must be thread-safe. */ std::pair<bool, std::string> CDocument::FILE_UpdatePatternList(const std::vector<std::string>& vectorPattern, const gd::argument::shared::arguments& argumentsList, int iThreadCount) { assert(vectorPattern.empty() == false); // Ensure the pattern list is not empty assert(vectorPattern.size() < 64); // Ensure the pattern list contains fewer than 64 patterns using namespace gd::table; gd::parse::patterns patternsFind(vectorPattern); patternsFind.sort(); // Sort patterns by length, longest first (important for pattern matching) auto* ptableFile = CACHE_Get("file"); // Retrieve the "file" cache table auto* ptableLineList = CACHE_Get("file-linelist", true); // Ensure the "file-linelist" table is in cache assert(ptableFile != nullptr); assert(ptableLineList != nullptr); std::string_view stringSegment; if( argumentsList.exists("segment") == true ) { stringSegment = argumentsList["segment"].as_string_view(); } // Get the segment (code, comment, string) to search in uint64_t uMax = argumentsList["max"].as_uint64(); // Get the maximum number of lines to process auto uFileCount = ptableFile->get_row_count(); // Total number of files to process // ## Thread synchronization variables std::atomic<uint64_t> uAtomicFileIndex(0); // Current file being processed std::atomic<uint64_t> uAtomicProcessedCount(0); // Count of processed files std::atomic<uint64_t> uAtomicTotalLines(0); // Total lines found across all threads std::mutex mutexLineList; // Mutex to protect ptableLineList access std::vector<std::string> vectorError; // Collect errors from all threads std::mutex mutexErrors; // Mutex to protect access to vectorError // ## Prepare columns for line list table detail::columns* pcolumnsThread = new detail::columns{}; ptableLineList->to_columns( *pcolumnsThread ); // ## Worker function to process files in parallel ......................... auto process_ = [&](int iThreadId) -> void { // Create thread-local table for collecting results std::unique_ptr<table> ptableLineListLocal = std::make_unique<table>(pcolumnsThread, 10, ptableLineList->get_flags(), 10); // Create local table with 10 rows pre-allocated while( true ) { // Get next file index to process uint64_t uRowIndex = uAtomicFileIndex.fetch_add(1); // get thread safe current index and increment it if(uRowIndex >= uFileCount) { break; } try { // STEP 1: Get file info (ptableFile is read-only so no mutex needed) auto stringFolder = ptableFile->cell_get_variant_view(uRowIndex, "folder").as_string(); auto stringFilename = ptableFile->cell_get_variant_view(uRowIndex, "filename").as_string(); // STEP 2: Build full file path gd::file::path pathFile(stringFolder); pathFile += stringFilename; std::string stringFile = pathFile.string(); auto uKey = ptableFile->cell_get_variant_view(uRowIndex, "key").as_uint64(); // STEP 3: Find lines with patterns gd::argument::shared::arguments arguments_({{"source", stringFile}, {"file-key", uKey}}); if( stringSegment.empty() == false ) arguments_.set("segment", stringSegment.data()); // Set the segment (code, comment, string) to search in auto result_ = COMMAND_ListLinesWithPattern(arguments_, patternsFind, ptableLineListLocal.get()); // Find lines with patterns and update the local table, ptableLineListLocal is thread-local if(result_.first == false) { std::lock_guard<std::mutex> lockErrors(mutexErrors); vectorError.push_back("File: " + stringFile + " - " + result_.second); // Update progress even on failure uint64_t uProcessed = uAtomicProcessedCount.fetch_add(1) + 1; if(uProcessed % 10 == 0) { uint64_t uPercent = (uProcessed * 100) / uFileCount; MESSAGE_Progress("", {{"percent", uPercent}, {"label", "Find in files"}, {"sticky", true}}); } continue; // Skip to next file on error } // STEP 4: Append results to main table (FAST operation - mutex needed for thread safety) { std::lock_guard<std::mutex> lockLineList(mutexLineList); ptableLineList->append(ptableLineListLocal.get()); // Append the results from the local table to the main table // Update total line count and check if we've exceeded the maximum uint64_t uCurrentLines = uAtomicTotalLines.fetch_add(ptableLineListLocal->get_row_count()) + ptableLineListLocal->get_row_count(); if( uCurrentLines > uMax ) { uAtomicFileIndex.store(uFileCount); // Signal other threads to stop by setting file index to max } } ptableLineListLocal->row_clear(); // Clear local table rows for next iteration // Update progress (thread-safe) uint64_t uProcessed = uAtomicProcessedCount.fetch_add(1) + 1; if(uProcessed % 10 == 0) // Show progress every 10 files { uint64_t uPercent = (uProcessed * 100) / uFileCount; MESSAGE_Progress("", {{"percent", uPercent}, {"label", "Find in files"}, {"sticky", true}}); } } catch(const std::exception& exception_) { std::lock_guard<std::mutex> lockErrors(mutexErrors); vectorError.push_back(std::string("Thread ") + std::to_string(iThreadId) + " error: " + exception_.what()); } } }; // ## Prepare and run threads .............................................. if( iThreadCount <= 0 ) { iThreadCount = std::thread::hardware_concurrency(); } // Use hardware concurrency if no thread count is specified if(iThreadCount <= 0) { iThreadCount = 1; } // Fallback to single thread if hardware_concurrency returns 0 if( iThreadCount > 8 ) { iThreadCount = 8; } // Limit to 8 threads for performance and resource management if( ptableFile->size() < iThreadCount ) { iThreadCount = (int)ptableFile->size(); } // Limit threads to number of files // Create and launch worker threads std::vector<std::thread> vectorPatternThread; vectorPatternThread.reserve(iThreadCount); for(int i = 0; i < iThreadCount; ++i) { vectorPatternThread.emplace_back(process_, i); } // Wait for all threads to complete for(auto& threadWorker : vectorPatternThread) { threadWorker.join(); } MESSAGE_Progress("", {{"clear", true}}); // Clear progress message // ### Handle any collected errors if(!vectorError.empty()) { for(const auto& stringError : vectorError) { ERROR_Add(stringError); } } return {true, ""}; }

Dold text
Skrivet av orp:

Möjligen naturligt för dig men definitivt inte för mig.

Hur kan detta vara så svårt?
Man väljer det som är naturligt för teramet. Om du ingår i ett team med 5 personer, då bestämmer NI hur ni skall skriva koden så ni bäst förstår varandras kod.
Om alla i ert team istället väljer att ni skriver som ni själva vill, helt ok men räkna inte med att ni kommer slå andra team som är sammasvetsade.
Ni kommer spendera betydligt mer tid på att fundera vad andra har skrivit för något om ni väljer att strunta i att ha gemensamt regelverk för namngivning

Skrivet av orp:

Det är för att folk inte tycker om det. Varför lägger du inte till radnumret för vart variabeln är deklarerad i variabelnamnet, då får du ju ännu mer info om variabeln och vet ju exakt vart den är deklarerad om du skulle behöva ändra det? Varför drar du linjen vid typ-info?

Få utvecklare gillar att anpassa sig, försök få någon att byta editor, byta dator, kanske endast byta font. Det är svårt
Men om de är tävlingsinriktade och vill nå ett mål så går det lättare.

Permalänk
Medlem
Skrivet av klk:

Vill man ha önskad funktionalitet är det ibland svårt att undvika sådant här så vet du hur jag skall lösa det är jag tacksam för hjälp

Ditt kodexempel är meningslöst.

Skrivet av klk:

Hur kan detta vara så svårt?

Hur svårt kan det vara att skriva utan?

Permalänk
Medlem
Skrivet av klk:

Försöker att bygga så mycket som möjligt på kod som återanvänds, den behöver inte testas.

Om du har fel på ett ställe så vill du att all kod ska vara konsekvent fel?

Du testar alltså inte? Testar ni inte på jobb heller?

Permalänk
Medlem
Skrivet av orp:

Varför lägger du inte till radnumret för vart variabeln är deklarerad i variabelnamnet, då får du ju ännu mer info om variabeln och vet ju exakt vart den är deklarerad om du skulle behöva ändra det? Varför drar du linjen vid typ-info?

Jag tror jag fick några små insikter om den här rätt meningslösa diskussionen om Hungarian Notation genom att läsa https://www.joelonsoftware.com/2005/05/11/making-wrong-code-l...

Snubben säger ungefär så här:

Dåligt: System Hungarian: Prefixa namn på symboler (i praktiken variabler, funktioner i C) med typ från språkets typsystem eller dina egendefinierade typer. Något Microsoft gjorde i stor skala eftersom de hade missförstått varför man skulle prefixa grejer.

Bra: Apps Hungarian: Prefixa namn med någon viktig info om hur symbolen ska användas, typiskt för att skilja på variabler av samma typ i språket som aldrig korrekt kan användas på samma sätt i domänen. Exemplet är koordinater som är relativa mot olika saker och som alla är typade som int.

Jag kan inte undgå att tro att System Hungarian hade rätt mycket att göra med Cs och speciellt K&R Cs rätt hjärndöda funktionsdeklarationer, speciellt i samband med int.

Jag är antagligen jättesen till den här insikten. Ni får ursäkta att jag inte lusläser tråden.

Att nödvändigtvis sätta kvalificerare som ett prefix ser jag inte som livsnödvändigt, men antagligen är det rätt naturligt. decodedBuf vs bufDecoded känns rätt skitsamma, oavsett om Buf är en typ i typsystemet eller inte.

Jag tycker också att det är underhållande att klk tycker att alla som inte använder Hungarian inte har några namngivningsregler. Jag hade givit exempel från C-kodstandarden jag har att förhålla mig till om jag hade trott att det hade varit meningsfullt.

Permalänk
Medlem
Skrivet av orp:

Om du har fel på ett ställe så vill du att all kod ska vara konsekvent fel?

Varför testa kod som körs över allt (att den körs innebär att den också testas), det är bästa testet.

Enhetstester är väl egentligen mest för att testa hårdkodade metoder

Permalänk
Medlem
Skrivet av KAD:

Dåligt: System Hungarian: Prefixa namn på symboler (i praktiken variabler, funktioner i C) med typ från språkets typsystem eller dina egendefinierade typer. Något Microsoft gjorde i stor skala eftersom de hade missförstått varför man skulle prefixa grejer.

Bra: Apps Hungarian: Prefixa namn med någon viktig info om hur symbolen ska användas, typiskt för att skilja på variabler av samma typ i språket som aldrig korrekt kan användas på samma sätt i domänen. Exemplet är koordinater som är relativa mot olika saker och som alla är typade som int.

Nämner att det inte finns något som heter "System Hungarian" eller "Apps Hungarian", det här är endast två val som olika team på microsoft använt sig av. Läser man Wiki eller minsta lila om om olika förklaringar så är det inte svårt att förstå. Att förklaringar på Wiki är skrivna av någon som inte begripit

Permalänk
Medlem
Skrivet av klk:

Varför testa kod som körs över allt (att den körs innebär att den också testas), det är bästa testet.

Nu har jag hört detta tillräckligt många gånger. Hoppas företaget du jobbar åt inte råkar läcka användardata och det sedan kommer fram att ni inte testat er kod för då lär det kosta.

Permalänk
Medlem
Skrivet av orp:

Nu har jag hört detta tillräckligt många gånger. Hoppas företaget du jobbar åt inte råkar läcka användardata och det sedan kommer fram att ni inte testat er kod för då lär det kosta.

Jag vet inte varför det inte går in men repetition för (tappat räkningen), enhetstester är för dåliga. De duger inte
Det är nära nog en 100% regel att de som grottar ner sig i enhetstester (nybörjare) har massiva problem med deras kod

Permalänk
Medlem
Skrivet av KAD:

Jag tror jag fick några små insikter om den här rätt meningslösa diskussionen om Hungarian Notation genom att läsa https://www.joelonsoftware.com/2005/05/11/making-wrong-code-l...

Jag kan ju avslöja att jag också lägger till typer ibland också. Exempelvis skapar jag ett tar-arkiv i min kod och då har jag tar_file och tar_path som variabler men HN är överdrivet enl. mig. Det är mest att @klk gör extrema utlåtande som att man blir X gånger mer produktiv om man använder HN. Där jag bara försöker att hävda att allting är inte så svart och vitt som @klk vill framställa saker som.

Skrivet av KAD:

Jag kan inte undgå att tro att System Hungarian hade rätt mycket att göra med Cs och speciellt K&R Cs rätt hjärndöda funktionsdeklarationer, speciellt i samband med int.

Både jag och min sambo har vars ett exemplar av K&R i bokhyllan men inget som smittat av sig.

Skrivet av KAD:

Jag tycker också att det är underhållande att klk tycker att alla som inte använder Hungarian inte har några namngivningsregler. Jag hade givit exempel från C-kodstandarden jag har att förhålla mig till om jag hade trott att det hade varit meningsfullt.

Det jag försökte säga i tidigare inlägg att jag bryr mig mer om väl namngivna variabler utan typinfo än att variabler måste innehålla typinfo.

Permalänk
Medlem
Skrivet av klk:

Jag vet inte varför det inte går in men repetition för (tappat räkningen), enhetstester är för dåliga.

För att jag ber dig bevisa det.

Permalänk
Medlem
Skrivet av orp:

För att jag ber dig bevisa det.

Så fort jag försöker så skiter du bara i det, har postat upp exempelkod och frågat hur den skall testas med enhetstester men inte fått någon lösning.

Om jag har en strängmetod som räknar längd och skriver tester för den så lägger jag tid på fel saker dom du förstår

Permalänk
Medlem
Skrivet av klk:

Så fort jag försöker så skiter du bara i det, har postat upp exempelkod och frågat hur den skall testas med enhetstester men inte fått någon lösning.

Du kan inte vara seriös...

Om du säger att enhetstest är för dåliga. Jag ber dig bevisa det. DÅ KAN DU JU INTE BE MIG VISA DIG HUR DU SKRIVER ENHETSTESTER FÖR DIN KOD.... Då har du sagt "Jag vet inte hur jag skriver enhetstester för min egen kod"... Om du inte vet hur du skriver enhetstester då har du ju ingen aning vad du snackar om... begriper du inte detta?

Jag är konsult, vill du att jag ska implementera unit tester för din kod så ligger mitt arvode på 1500:-/tim, vill du att jag ska sätta dig i kontakt med min säljare? Du kommer få din kod omskriven i C, Rust, Erlang, Python eller Go med unit tester för jag rör inte C++ med tång.

När jag ger exempel så försöker jag göra dom väl avgränsat så vi kan hålla en diskussion om vad som är relevant men då byter du ämne för att månen står fel eller du har en fis på tvären eller HN knackade på dörren och bad om att få se din TV-licens eller något annat...

Permalänk
Medlem
Skrivet av orp:

Jag kan ju avslöja att jag också lägger till typer ibland också. Exempelvis skapar jag ett tar-arkiv i min kod och då har jag tar_file och tar_path som variabler men HN är överdrivet enl. mig.

Det här är inget svar för att du också använder

Utan skall beskriva det absurda i om man tror på System hungarian eller Apps hungarian för wiki har helt förstört massor eftersom det står fel
https://en.wikipedia.org/wiki/Hungarian_notation

## Variables Extracted: 1. **`lAccountNum`** - **Prefix**: `l` (long integer) - **Purpose**: Represents a long integer value, specifically an account number 2. **`arru8NumberList`** - **Prefix**: `arr` (array) + `u8` (unsigned 8-bit integers) - **Purpose**: Represents an array of unsigned 8-bit integers, likely a list of numbers 3. **`bReadLine`** (function) - **Prefix**: `b` (byte-value return code) - **Purpose**: Function that returns a byte-value status/return code - **Parameters**: Takes a port reference and the number list array 4. **`strName`** - **Prefix**: `str` (string) - **Purpose**: Represents a string containing a name (implementation unspecified) 5. **`rwPosition`** - **Prefix**: `rw` (row) - **Purpose**: Represents a row position, likely in a table or grid 6. **`usName`** - **Prefix**: `us` (unsafe string) - **Purpose**: Represents raw/unvalidated user input that requires sanitization 7. **`szName`** - **Prefix**: `sz` (zero-terminated string) - **Purpose**: Represents a null-terminated C-style string

Om man inte förstår att dessa förkortningar är valda för att de passar specifikt projekt så bör man kanske fundera om man passar till programmering.
Varför skulle någon välja rw som prefix? Det är uppenbart att det är från Excel teamet.

C++ idag jobbar sällan med nullterminerade strängar, de har string eller string_view, då behövs inte sz, något som förr när inte de här objekten fanns för att kapsla in strängar, då drällde det av den typen av strängar (jobba med text är vanligt...).

Om man automatiskt utgår från att "oj, vilka idioter som skrev variabler på det viset" då kanske felet ligger hos en själv, att man inte begriper att kod på 1990 talet såg annorlunda ut mot vad den gör idag, att hårdvara var annorlunda, att skärmar och annat var annorlunda.
Det här är en lösningsförslag av personer som i nästan alla situationer hade lämnat de flesta av dagens utvecklare långt bakom.
Nivån för att klara C kod för windows på 1990 talet var löjligt hög

Permalänk
Medlem
Skrivet av orp:

Jag är konsult

Känner du till begreppet "konsultkod"
Där håller jag med, du måste skriva test

Konsulter behöver generellt rusa fram kod, det finns inte tid att tänka igenom

Permalänk
Medlem
Skrivet av klk:

Så fort jag försöker så skiter du bara i det, har postat upp exempelkod och frågat hur den skall testas med enhetstester men inte fått någon lösning.

Om kod skall testas med enhetstester så måste koden skrivas så att det går någorlunda enkelt att skriva enhetstester för den.
Om man skriver kod utan att tänka på hur den skall testas så är det ofta inte så lätt att skriva vettiga enhetstester för den.

Den kod du postat är ganska tydligt inte skriven med enhetstester i åtanke.

Uppenbarligen så vet du varken hur man skriver eller använder enhetstester, så hur du då kan "veta" att de inte fungerar är märkligt.

Permalänk
Medlem
Skrivet av klk:

Om man inte förstår att dessa förkortningar är valda för att de passar specifikt projekt så bör man kanske fundera om man passar till programmering.

För dig är variabelnamn det viktiga och inte logiken, got it!

Skrivet av klk:

Varför skulle någon välja rw som prefix? Det är uppenbart att det är från Excel teamet.

För att det står för read write och jag kunde inte bry mig mindre om Excel.

Skrivet av klk:

C++ idag jobbar sällan med nullterminerade strängar, de har string eller string_view, då behövs inte sz

Jag jobbar med C så jag föredrar mina strängar nullterminerade så jag behöver inte heller sz.

Skrivet av klk:

Om man automatiskt utgår från att "oj, vilka idioter som skrev variabler på det viset" då kanske felet ligger hos en själv

Om man automatiskt utgår ifrån att man inte kan ha stora välstrukturerade kodprojekt utan HN då ligger felet hos dig.

Permalänk
Medlem
Skrivet av Erik_T:

Den kod du postat är ganska tydligt inte skriven med enhetstester i åtanke.

Uppenbarligen så vet du varken hur man skriver eller använder enhetstester, så hur du då kan "veta" att de inte fungerar är märkligt.

Bara för att jag inte låser koden med enhetstester så betyder det inte att jag inte använder enhetstester

Så fort jag gör något nytt skrivs nästan allt med tester, för nyutveckling fungerar det kanon

Men du får gärna lära mig hur du skulle skrivit om koden så den fungerar med tester eller om du har en alternativ lösning, tänker då att du bara beskriver övergripande för förstår självklart att om man skall _skriva_ om koden så går det inte.

Hur gör du själv när du testar trådade lösningar?

Permalänk
Medlem
Skrivet av klk:

Känner du till begreppet "konsultkod"
Där håller jag med, du måste skriva test

Konsulter behöver generellt rusa fram kod, det finns inte tid att tänka igenom

Så varför ber du mig skriva dina enhetstest åt dig istället för att lägga fram bevis för varför dom är så dåliga? Byter ämne igen?

Permalänk
Medlem
Skrivet av klk:

Bara för att jag inte låser koden med enhetstester så betyder det inte att jag inte använder enhetstester

Så fort jag gör något nytt skrivs nästan allt med tester

Men du får gärna lära mig hur du skulle skrivit om koden så den fungerar med tester eller om du har en alternativ lösning, tänker då att du bara beskriver övergripande för förstår självklart att om man skall _skriva_ om koden så går det inte.

Hur gör du själv när du testar trådade lösningar?

Är det inte bättre att du lär dig enhetstestning innan du öppnar munnen?

Permalänk
Medlem
Skrivet av orp:

Så varför ber du mig skriva dina enhetstest åt dig istället för att lägga fram bevis för varför dom är så dåliga? Byter ämne igen?

ok, postar den här om det är så svårt att komma ihåg

Permalänk
Medlem
Skrivet av klk:

ok, postar den här om det är så svårt att komma ihåg

Har du bytt till JS och varför ska jag kolla på en video från Theo som också har en rad missförstånd om unit testning som han senare erkänt i samtal med ThePrimeagen?

TL;DR om du kodar du komplexa saker så bör du unit testa.

Permalänk
Medlem
Skrivet av orp:

Har du bytt till JS och varför ska jag kolla på en video från Theo som också har en rad missförstånd om unit testning som han senare erkänt i samtal med ThePrimeagen?

Fråga: Hur verifierar du att det är bra tester?