Programmering i andras ögon?

Bara för att man anser att luft är viktigare än vatten för att överleva så betyder inte det att vatten är värdelöst.

Dokumentation, test och kommentarer fyller olika funktioner och kan (och bör) alla existera samtidigt. Dokumentationen (som initialt kanske enbart består av en specifikation) är rättesnöret för testens utformning, testsviten ser till att koden gör vad den ska, kommentarer kan hjälpa till med att förklara hur koden gör det den ska på en nivå som kan vara fullständigt ointressant för både dokumentationen och/eller testen.

Ligger jag beroende av maskiner så hoppas jag att mjukvaran utvecklats av ett team som inte blint förespråkar en viss isolerad utvecklingsmetod framför andra beroende på vad som är "modernt" eller ej. Livsuppehållande maskiner eller kritisk styrningsmjukvara kan kräva andra metoder än vetenskaplig analyskod, som kan kräva andra metoder än webbutveckling, som kan kräva andra metoder än interna affärssystem, etc.

unit-test: visar de typiskt att varje separat modul faktiskt implementerar sitt externa API
integrations-test: visa att moduler kan kombineras via sina externa APIer på önskvärt sätt
system-test: visar t.ex. prestanda/skalbarhet uppfyller målen, har man ett GUI testar man att det är användbart

Inget av detta svarar på frågan varför du gjort på ett visst sätt. Behovet att att behöva dokumentera hur saker fungerar minskas inte heller av tester, det minskar man genom att bryta ner sitt program i mindre bitar så namnet på funktionen beskriver uppgiften och implementationen är så trivial att det är uppenbart hur den fungerar, tror alla här är överens om just detta. Här tycker jag McCabe cyclomatic complexity är ett väldigt bra hjälpmedel, håller man alla funktioner/metoder under 5-6 är logiken normalt sett trivialt, det är lämpligt att ha hårt gräns på runt 10 (går att testa automatiskt att all kod håller sig under ett visst värde).

Tror nog alla är med på detta.

Det behövs fortfarande kommenterar för varför. Det behövs också dokumentation vad externa API förväntas lösa för uppgift, lämpligen har man även exempel som visar hur APIet är tänkt att användas. Vare sig tester eller välskriven/enkel kod ersätter detta.

Läser du dokumentationen på MSDN eller tittar du i källkoden för .NET när du ska lura ut hur saker fungerar?

Vadå inte programmering? Du bygger ju upp ett utseende, inte bara på texten och var texten ska befinna sig och i vilken form utan även om du nu gör en hemsida hur den ska se ut osv. Givetvis är det programmering men det är väl inte i den mest avancerade formen

Det där står om bara HTML, som har mest med text att göra, hen jag svarade nämnde både HTML och CSS. Sedan förstår jag inte varför det inte skulle vara programmering, man skriver kod som ger instruktioner till någonting. Bara för att man inte programmerar ett program eller en maskin så är det ju fortfarande samma princip, du ger genom ett datorspråk instruktioner om utseende och vad som skall hända när man gör si och så. HTML och CSS är en form av programmering men mer inom webben, därför brukar man även kalla det webbprogrammering

Läser väldigt ofta genererad assembler när jag jobbar med prestandakritiska komponenter för att se att de konstruktioner man valt inte ställer till det för kompilatorn, skulle aldrig vilja använda något bara baserat på detta.

Har för att helt förstå saker som async/await och liknande genom att läsa CIL. Det senare är knappast ett substitut för informationen på MSDN, skulle vara extremt ineffektivt att försöka använda en ramverk/bibliotek på det sättet.

Kod utan kommenterar kring hur man ska använda produkten håller inte hög kvalité för den som ska använda den, effektivare/mer utbroderande att läsa vanligt skrivet språk som förklarar detta än läsa koden. Kod utan kommenterar kring varför kommer med stor sannolikhet få buggar introducerade i framtiden av välmenande personer som ska "förenkla" något.

Jo det är det, en länk till exempel, men sakerna som du "programmerar" är väldigt simpla helt enkelt, varför utesluter du dessa datorspråk? När jag kollar upp vad programmering är för något, så står det inte precis att det är en gräns där för simpla saker inte är inräknade. Du tycker säkert också att många företag har fel då eftersom dom använder begreppet "webbprogrammering" när dom pratar om HTML, CSS, Javascript m.m. Vet inte om det är detta du tänker på men är det så att du tänker mer på programmerare snarare än programmering? En programmerare till exempel är ju inte bara någon som skriver kod. Jag kan skriva kod, men det gör mig inte till en programmerare, utan en kodare. Men en programmerare kan skriva kod i HTML och fortfarande programmera, dock i en begränsad och enkel form. Sen kanske man brukar kalla HTML för markup language, vilket inte är fel (står ju för HyperText Markup-Language), men tycker inte det är fel att säga att det även är med i kategorin "programmering".

PS: Vet inte om det är den bästa jämförelsen men man kanske kan ta en cykel och en motorcykel, båda är inom samma kategori "cykel", båda har ett styre, två hjul osv, men den ene är bra mycket mer avancerad. Dom är inom samma kategori, men dom är inte samma sak

Alltså programmering är ju inte endast kodningen, att skriva kod. Att programmera är mycket mer än så och det gäller alla datorspråk, om du skriver i CSS eller om det är .NET, skriver man endast koden så programmerar man inte.

Simpel programmering är fortfarande programmering. "Hello World!" är det första steget för i stort sett alla programmerare. Python är ett enkelt språk, fortfarande programmering.

Företag använder ofta begrepp fel. Någon som enbart arbetar med HTML, CSS etc är inte programmerare, det är en webbdesigner.

HTML är fortfarande markup, inte programkod. Du kan inte skapa programkod med HTML.

Jo, det är fel. Du kan inte skapa ett datorprogram i ett markup-språk.

Alla försök att jämföra programmering blir dåliga, i synnerhet då de oftast är fel på ett eller annat plan.

Programmering består av mycket mer än kodknackande, ja. Det får fortfarande inte CSS att bli ett programmeringsspråk, det är markup. Du kan inte skriva ett datorprogram med CSS hur gärna du än vill.

Skillnaden är att HTML och CSS inte kan skapa en exekverbar maskinkod. Du kan inte säga att du programmerar när du inte skriver ett program.

Nu fanns det rätt mycket att önska vad det gäller att inkludera exempel på hur APIet var tänkt att används och "dokumentationen" var i många fall namnet på funktionen med mellanslag mellan order i stället för CamelCase.

Men hur har du tänkt generera API-dokumentation? Hur har du tänkt dig att någon ska orka använda något som inte är mer eller mindre trivialt utan någon form av exempel och beskrivning kring hur APIet är tänkt att används?

C# XMLDoc verkar inte alls fått samma genomslag som t.ex. JavaDoc, vilket är trist. Kan ta ett exempel, har använt OpenCL en del från C men ville köra det från Java i stället och hittade JavaCL. Även om dokumentationen kan lämna en del att önska så är ändå deras JavaDoc-sida extremt värdefull för någon som har en rätt bra idé kring vad OpenCL är och hur de används i C eller C++.
Ovanpå detta har de även en rätt ok getting started sida. Men hjälp av den och JavaDoc sidan hade jag en fungerande applikation inom väldigt kort tid, utan JavaDoc skulle jag klassa hela detta projekt som värdelöst då jag aldrig skulle orka sitta och läsa koden med mindre än att det var absolut det enda sättet och jag absolut måste använda detta bibliotek.

Och sedan har det nämnts många gånger, dokumentation inne i koden ska typiskt bara dokumentera varför, filen du listade var kliniskt ren från sådan kommentarer.

-- Kvalar skapandet av det här in som programmering? (Det är alltså inget program i sin klassiska betydelse)
-- Jag själv brukar aktivt välja andra ord än programmering om det här.. Rolig kodning är det i vilket fall!

library ieee;
    use ieee.std_logic_1164.all;
    use ieee.numeric_std.all;

entity mac is
  port(clk : in  std_logic;
        ds : in  std_logic;
        a  : in  std_logic_vector(15 downto 0);
        b  : in  std_logic_vector(15 downto 0);
        p  : out std_logic_vector(47 downto 0);
end entity;

architecture vhdl of mac is
   signal pi : signed(p'range):=(others=>'0');
begin
   p<=std_logic_vector(pi);
   process(clk)
   begin
      if rising_edge(clk) then
         if ds='1' then
            pi<=resize(signed(a)*signed(b),pi'length);
         else
            pi<=signed(a)*signed(b)+pi;
         end if;
      end if;
   end process;
end architecture;

Jag föredrar att koden är lättläst, välkommenterad och väl dokumenterad.
Kanske någon av er föredrar något annat, men jag har svårt att förstå varför.