Permalänk
Avstängd
Skrivet av Shimonu:

Min poäng är enkel. Utvecklare som utvecklar egna automatiska tester är mer riskabelt än oberoende testare. Det finns därmed situationer där man inte vill tillåta utvecklare att testa sin egen kod. Jag gick emot uttalandet att utvecklare alltid ska utveckla egna unittester.

Det du tänker på är automatiserade acceptanstester, det är inte enhetstester. Enhetsteser är mindre blackbox-tester som testar klassen eller funktionen att den spottar ut sig vad som förväntas på detta sätt kan man utan risk för fel ändra kod utan att förstöra beteende. Den säkerställer inte att koden gör rätt enligt krav. Jag tycker även det är bra skriva enhetstester som återskapar rapporterade buggar innnan man börjar rätta buggen

Visa signatur
Permalänk
Avstängd
Skrivet av backfeed:

Kommentarer skall alltid användas om något görs som definitivt inte är uppenbart självförklarande, det är bra särskilt för andra inblandade (medarbetare eller någon som i framtiden tar över ens projekt) men även för en själv.

Alla jag känner som anser att källkod = dokumentation brukar inte sällan skriva kod som är svår eller omöjlig att begripa, vilket är extremt irriterande. Särskilt när de använder värdelösa namn på klasser, metoder och variabler som inte beskriver innehållet överhuvudtaget.

Du kan inte anse att kod är dokumentation om du itne skriver beskrivande och lättförstådd kod

Visa signatur
Permalänk
Medlem

Tja, ibland behövs både ramverk och kommentarer...
exempel:
http://llvm.org/doxygen/LoopStrengthReduce_8cpp_source.html

Permalänk
Medlem

Mina åsikter:
I applikationskod kommenterar man undantagsfall och saker som inte är glasklara vid en första anblick. Kod och namngivning av variabler/funktioner ska i normalfallet räcka som dokumentation. Det är sällan man kollar på kod och inte förstår vad den gör, däremot händer det betydligt oftare att man ser kod som man inte vet _varför_ den ser ut som den gör.

För bibliotek gäller något helt annat, dock samma krav generellt för implementationsbiten av biblioteken.

Skickades från m.sweclockers.com

Visa signatur

Citera mig för svar.
Arch Linux

Permalänk
Medlem
Skrivet av JesseJames:

Tja, ibland behövs både ramverk och kommentarer...
exempel:
http://llvm.org/doxygen/LoopStrengthReduce_8cpp_source.html

My man! 5 500 rader i en fil!

Visa signatur

Välkommen till Sweclockers F1 fantasy Kod 476f003b55

Permalänk
Hedersmedlem

Nu håller jag inte på med programmering personligen, men har ändå några erfarenheter från jobbet där en maskin blivit stående längre än nödvändigt när inställningarna försvann efter ett strömavbrott, och där ingen del av koden var kommenterad, vilket gjorde det mer eller mindre omöjligt att felsöka eller gissa. Fanns naturligtvis ingen backup heller, men som tur var fanns det en likadan maskin man kunde kopiera inställningarna ifrån.

Kommentarer för att dela in olika funktioner (t.ex. "Uppstartssekvens", "Förreglingskrets" etc.) tycker jag är bra för att underlätta vid felsökningar och snabbt kunna hoppa till aktuell kodstycke. Beskrivning av själva funktionen eller dylikt tycker jag väl är lite överflödigt, men om det ska göras tycker jag dock att man bör datumstämpla kommentaren så man faktiskt vet ifall den är relevant eller ej.

Visa signatur

"The more you learn, the more you realize how little you know."

Permalänk
Medlem
Skrivet av JesseJames:

Tja, ibland behövs både ramverk och kommentarer...
exempel:
http://llvm.org/doxygen/LoopStrengthReduce_8cpp_source.html

Att det sen råkar vara en källfil från en av de mest komplexa områdena som existerar hör ju inte alls till saken

Skickades från m.sweclockers.com

Visa signatur

Citera mig för svar.
Arch Linux

Permalänk
Medlem

@CyberVillain: Nu vet jag inte i vilka sammanhang du pratar om. För även en spelmotor kan ha avancerad implementation eller avancerad logik.

Jag ska vara öppen och ärligt säga att, för de enkla exemplen du angett, så har du en poäng. I (nästan) alla andra fall har du fel.

För när du jobbar med någonting och har en spetskunskap inom ämnet, d.v.s. där implementationen är på avancerad nivå, så är du dödsdömd om du inte använder kommentarer.

Kan get ett simpelt exempel med C/C++ syntax:

bool isSensitive(Object car, Object wall, int alpha, float e) { car.attach(&wall); Matrix A = car.getMesh(); Matrix B = wall.getMesh(); A.transpose(); Matrix X = alpha*A*B; X.clean(); float condition_number = divergence(X)*condition(X); if(condition_number < e) return false; else return true; }

När jag tittar på den här koden så är funktionens syfte självförklarande. MEN! Jag har ändå tusen frågor om dess villkor. Jag kan bjuda på ett par frågor så förstår du lättare vad jag menar:
1. Funktionen tar in car, wall, alpha och e i sina respektive former. Sedan plockar funktionen ut matriserna A och B från respektive Object. Kan A och B vara singulära?
2. Måste A vara ortogonal?
3. Vad är gränserna för alpha?
4. Får A och B vara komplexa?
5. Vilken IEEE standard följer funktionen för flyttal? Hur stor påverkan har det?
6. Vad gör clean() för något? Kan clean() returnera dåligt svar/kod? Vad händer då?
7. Tar if-satsen hänsyn till väldigt små tal? Vad händer om det är så litet tal att jämförelsen är mindre än maskinfelet epsilon?
8. o.s.v.

Dessa frågor kan du OMÖJLIGT svara på genom att bara titta på koden. Utan kommentarer så kommer man inte långt. Har lärt mig det den hårda vägen.

Kör du däremot detta så behövs nog ingen rapport om vad som händer

void setName(Object container) { if(container.hasContent()) this.name = container.name; else exceptionHandler(container.getException()); }

*reserverar mig för syntaxfel*

Permalänk
Hedersmedlem
Skrivet av CyberVillain:

Det du tänker på är automatiserade acceptanstester, det är inte enhetstester. Enhetsteser är mindre blackbox-tester som testar klassen eller funktionen att den spottar ut sig vad som förväntas på detta sätt kan man utan risk för fel ändra kod utan att förstöra beteende. Den säkerställer inte att koden gör rätt enligt krav. Jag tycker även det är bra skriva enhetstester som återskapar rapporterade buggar innnan man börjar rätta buggen

Ja, det kan vara bra men det finns inte alltid utrymme(resurser) i ett projekt för utvecklare att utveckla egna tester och det passar inte alltid kodens livscykel. Jag menar bara att världen är inte så svartvit.

Nu är jag ute på hal is men ett enhetstest är väl enhetstest oavsett om det görs för acceptans eller regression? Samma enhetstest kan väl köras för båda? Vill bara förstå semantiken.

Permalänk
Avstängd
Skrivet av Shimonu:

Ja, det kan vara bra men det finns inte alltid utrymme(resurser) i ett projekt för utvecklare att utveckla egna tester och det passar inte alltid kodens livscykel. Jag menar bara att världen är inte så svartvit.

Nu är jag ute på hal is men ett enhetstest är väl enhetstest oavsett om det görs för acceptans eller regression? Samma enhetstest kan väl köras för båda? Vill bara förstå semantiken.

Oftast väldigt olika ramverk för dessa två typer av tester för acc/krav har jag använt spec-flow mycket..

Visa signatur
Permalänk
Avstängd
Skrivet av Casgar:

Nu håller jag inte på med programmering personligen, men har ändå några erfarenheter från jobbet där en maskin blivit stående längre än nödvändigt när inställningarna försvann efter ett strömavbrott, och där ingen del av koden var kommenterad, vilket gjorde det mer eller mindre omöjligt att felsöka eller gissa. Fanns naturligtvis ingen backup heller, men som tur var fanns det en likadan maskin man kunde kopiera inställningarna ifrån.

Kommentarer för att dela in olika funktioner (t.ex. "Uppstartssekvens", "Förreglingskrets" etc.) tycker jag är bra för att underlätta vid felsökningar och snabbt kunna hoppa till aktuell kodstycke. Beskrivning av själva funktionen eller dylikt tycker jag väl är lite överflödigt, men om det ska göras tycker jag dock att man bör datumstämpla kommentaren så man faktiskt vet ifall den är relevant eller ej.

Ett bra skrivet program är uppdelat i logiska moduler (klasser osv beroende på språk) som gör den formen av dokumentation helt överflödig.

Visa signatur
Permalänk
Medlem
Skrivet av CyberVillain:

Ett bra skrivet program är uppdelat i logiska moduler (klasser osv beroende på språk) som gör den formen av dokumentation helt överflödig.

Må så vara, men för övriga 99.5% av alla existerande program så är den formen av dokumentation/kommentarer rätt användbar.

För övrigt så har du ännu inte gett mycket argument för ditt ursprungliga påstående i den här tråden: Att "kommentarer är av ondo". Att de kan vara onödiga har det kommit argument för, men "av ondo"?

Närmaste som kommit i den vägen är väl att kommentarer kan bli föråldrade, men det gör ju inte att kommentarer i sig är något dåligt. Kod kan också bli föråldrad och utdaterad.

Permalänk
Avstängd
Skrivet av Alotiat:

@CyberVillain: Nu vet jag inte i vilka sammanhang du pratar om. För även en spelmotor kan ha avancerad implementation eller avancerad logik.

Jag ska vara öppen och ärligt säga att, för de enkla exemplen du angett, så har du en poäng. I (nästan) alla andra fall har du fel.

För när du jobbar med någonting och har en spetskunskap inom ämnet, d.v.s. där implementationen är på avancerad nivå, så är du dödsdömd om du inte använder kommentarer.

Kan get ett simpelt exempel med C/C++ syntax:

bool isSensitive(Object car, Object wall, int alpha, float e) { car.attach(&wall); Matrix A = car.getMesh(); Matrix B = wall.getMesh(); A.transpose(); Matrix X = alpha*A*B; X.clean(); float condition_number = divergence(X)*condition(X); if(condition_number < e) return false; else return true; }

När jag tittar på den här koden så är funktionens syfte självförklarande. MEN! Jag har ändå tusen frågor om dess villkor. Jag kan bjuda på ett par frågor så förstår du lättare vad jag menar:
1. Funktionen tar in car, wall, alpha och e i sina respektive former. Sedan plockar funktionen ut matriserna A och B från respektive Object. Kan A och B vara singulära?
2. Måste A vara ortogonal?
3. Vad är gränserna för alpha?
4. Får A och B vara komplexa?
5. Vilken IEEE standard följer funktionen för flyttal? Hur stor påverkan har det?
6. Vad gör clean() för något? Kan clean() returnera dåligt svar/kod? Vad händer då?
7. Tar if-satsen hänsyn till väldigt små tal? Vad händer om det är så litet tal att jämförelsen är mindre än maskinfelet epsilon?
8. o.s.v.

Dessa frågor kan du OMÖJLIGT svara på genom att bara titta på koden. Utan kommentarer så kommer man inte långt. Har lärt mig det den hårda vägen.

Kör du däremot detta så behövs nog ingen rapport om vad som händer

void setName(Object container) { if(container.hasContent()) this.name = container.name; else exceptionHandler(container.getException()); }

*reserverar mig för syntaxfel*

Nej jag pratar om domänkoden, för lågnivå som algoritmer kan kommentarer behövas.

Visa signatur
Permalänk
Avstängd
Skrivet av Erik_T:

Må så vara, men för övriga 99.5% av alla existerande program så är den formen av dokumentation/kommentarer rätt användbar.

För övrigt så har du ännu inte gett mycket argument för ditt ursprungliga påstående i den här tråden: Att "kommentarer är av ondo". Att de kan vara onödiga har det kommit argument för, men "av ondo"?

Närmaste som kommit i den vägen är väl att kommentarer kan bli föråldrade, men det gör ju inte att kommentarer i sig är något dåligt. Kod kan också bli föråldrad och utdaterad.

Trodde faktiskt jag skrev titeln som Kommentarer är av ondo (Oftast) men det gjorde jag tydligen inte. I ett välmående system är det väldigt få av dem. De är där inte för att förklara koden utan varför man gör som man gör.

Visa signatur
Permalänk
Medlem
Skrivet av Zipparn:

My man! 5 500 rader i en fil!

Vi har ett par filer i kodgeneratorn i våran out of tree target som är ytterligare någon rad stor

Permalänk
Avstängd

Sorry vart lite hård, ber om ursäkt. Men du borde fundera lite på din kodkvalitet!

Visa signatur
Permalänk
Medlem
Skrivet av Dimman:

Att det sen råkar vara en källfil från en av de mest komplexa områdena som existerar hör ju inte alls till saken

Skickades från m.sweclockers.com

Jo det handlade väl om att kommentarer var onödiga?
Här är ett exempel där det snarare finns lite för lite kommentarer ibland p g a komplexiteten.
Dessutom var det någon som inte såg nyttan med ramverk... Vi nyttjar gärna det här ramverket snarare än skriver ett eget

Permalänk
Medlem

Att kommentera bara för att kommentera är onödigt. SKillnaden är strukturerade kommentarer för exempelvis automatisk dokumentationsgenerering. Denna typ av kommentarer använder jag nog rätt ofta i egen skriven kod nu för tiden då det ger andra en snabb överblick av vad olika delar gör och ansvarar för och hjälper dem att sedan förstå koden i klassen/funktionen i fråga utan att bläddra runt i en massa extern dokumentation eller gissa. "Kod som förklarar sig själv" bör sällan dokumenteras, men man skall också vara medveten om att vad som är tydligt för en själv kanske inte är det för nästa person som kommer om fyra år och tvingas hoppa in i ens kod.

Jag har själv jobbat med flera system på flera hundra tusen rader kod där avsaknad av dokumentation eller kommentarer gjort att jag fått läsa en himla massa kod innan jag kunnat/vågat göra förändringar utan att de skulle få oförutsedda kaskadeffekter i resten av systemet.

Saker som inte är självförklarande eller som bryter ett mönster kommenterar jag alltid av detta skäl direkt i koden där denna sak förekommer. Eftersom jag är nogrann med comitts på ett issue åt gången så går det då lätt att hitta vad som exempelvis introducerade en bugg, när och lättare att förstå varför i och med kommentar som nämner vad man ville åstakomma med sin kludge.

Visa signatur

Gigabyte Aorus Master | 32gb DDR4 3466MHZ CL14 | Ryzen 3950X | 3080Ti
En lång rad Intel system som barnen fått som speldatorer, VR-dator, massa bärbara, servrar, RPi's och andra boxar :P

Permalänk
Medlem

Håller med alla som gillar kommentarer & anledningar till varför kommentarer är nyttiga, speciellt i större team & oavsett hur bra & "förklarande" funktions-/class/variabel -namnen är så finns det även övrig information att delge i kommentera & varför ens slösa tid på att kolla igenom en hel class tex för att hitta alla variabel-namn & övriga "beskrivande" namn i classen för att räkna ut dess funktion/syfte/output osv när en 20 teckens kommentar tar en bråkdel av tiden.

Dessutom är komplex kod komplex oavsett hur sjukt bra man än är på att namnge all kod

Visa signatur

Hur kan syltkakor överleva i det vilda utan ögon?

Permalänk
Medlem
Skrivet av CyberVillain:

Sorry vart lite hård, ber om ursäkt. Men du borde fundera lite på din kodkvalitet!

Äh, man ska säga vad man tycker och uttrycka sig färgstarkt! Jag trollar bara. Kommentarerna i mitt exempel är inte nödvändiga. Men ibland finns ställen där det passar bättre

Skickades från m.sweclockers.com

Visa signatur

Välkommen till Sweclockers F1 fantasy Kod 476f003b55

Permalänk
Medlem
Skrivet av JesseJames:

Vi har ett par filer i kodgeneratorn i våran out of tree target som är ytterligare någon rad stor

Jag har sett stora komplexa system där man följer kodflödet och hamnar i en switchsats som är typ 10000 rader. Ohhhhhh vad jag vill ha tid att refaktorera just då.

Visa signatur

Gigabyte Aorus Master | 32gb DDR4 3466MHZ CL14 | Ryzen 3950X | 3080Ti
En lång rad Intel system som barnen fått som speldatorer, VR-dator, massa bärbara, servrar, RPi's och andra boxar :P

Permalänk
Medlem
Skrivet av CyberVillain:

Nej jag pratar om domänkoden, för lågnivå som algoritmer kan kommentarer behövas.

I så fall är jag beredd att hålla med dig till viss gräns.

Finns alltid undantag när man vill varna för någonting (som i ditt exempel).

Permalänk
Medlem

Finns ju en gråzon också. Ibland kan det vara väldigt smidigt och bra med kommentarer och ibland blir det bara kladdigt. Så beror ju på.

Skickades från m.sweclockers.com

Visa signatur

Dator 1: | i9 9900k | MSI RTX 4080 Ventus 3x OC | ASUS ROG STRIX Z390-F Gaming | Corsair LPX DDR4 32 GB 3200Mhz | FD define S | Samsung 850 EVO 1TB | Samsung 980 NVMe M.2 1TB | Noctua NH-U12S | Corsair RM750x 750W | Windows 10
Skärm 1: ASUS 27" ROG SWIFT PG279Q 1440p @ 165Hz/IPS/G-Sync
Skärm 2: ASUS 27" TUF VG27AQ1A 1440p @ 170Hz/IPS/G-Sync/HDR

Permalänk
Hedersmedlem

@Airikr: Den där koden skulle kunna skrivas om till något liknande detta, vilket i min mening är mycket mer lättläst och inga kommentarer behövs.

if (postWasRead()) { addPostVisit(); if (userIsLoggedIn()) logPostVisitActivity(); }

Sedan tycker jag att kommentarer kan ha sin plats men det ska användas med syfte. I PHP skulle jag kunna tänka mig att man kan behöva ha kommentarer för att motivera varför man gör saker på ett visst sätt eftersom språket beter sig lustigt ibland.

Visa signatur

The variable 'brain' is declared but never used

Permalänk
Medlem
Skrivet av CyberVillain:

Du kan inte anse att kod är dokumentation om du itne skriver beskrivande och lättförstådd kod

Precis. Jag har bara dåliga erfarenheter av folk som tror att deras kod är beskrivande och lättförståelig (jag har ett par såna på jobbet).

Visa signatur

5950X, 3090

Permalänk
Avstängd
Skrivet av Zipparn:

Äh, man ska säga vad man tycker och uttrycka sig färgstarkt! Jag trollar bara. Kommentarerna i mitt exempel är inte nödvändiga. Men ibland finns ställen där det passar bättre

Skickades från m.sweclockers.com

Faktum är att den där formen av kommentar är inte helt ovanligt tex

//normalize the heading of player
Var normalizedHeading = heading.Normalized();

Lixom ja jag kan se det

Såhär ensamt kan de se oskyldig ut men en hel klass på detta vis, fyfan

Visa signatur
Permalänk
Avstängd
Skrivet av backfeed:

Precis. Jag har bara dåliga erfarenheter av folk som tror att deras kod är beskrivande och lättförståelig (jag har ett par såna på jobbet).

Tror gör man i kyrkan

Skickades från m.sweclockers.com

Visa signatur
Permalänk
Medlem

Det jag tycker många av er missar, även om jag inte helt håller med TS, är att han förespråkar god dokumentation UTANFÖR koden, något jag faktiskt håller med om.

När jag arbetade i ett stort projekt här för ett tag sedan, (hemsida - databas - applikation), så la vi otroligt mycket tid på att skriva API'er för hur varje del fungerade. Behövde man koppla något till databasen? Då fanns det API. Behövde man ändra något i appen? Då fanns det dokumentation - allt detta var utanför koden.

Visst, jag använder faktiskt också kommentarer ibland för att förklara viktiga saker, (inte för mitt eget bruk utan för andra personer). Men att komma till ett projekt med god dokumentation, bra API och lättnavigerade filer/mappar gör att jag sover bra om nätterna.

Något som vår scrummaster sa i början av projektet, (ja, en sån ska man tydligen ha nu för tiden), var att koden ska vara självkommenterande. Det var lite jobbigt till en början men som jag skrev tidigare i texten så underlättade det enormt senare.

Exempel på wiki från databasen:

Visa signatur

Gaming: RTX 2070 & 3770k
Studier: MacBook pro retina 13
Ljud: QH-1339 & ett par rackans smidiga AirPods
Telefon: iPhone 6s plus
Skärm: ASUS 27" ROG Swift PG279Q med sån där g-sync

Permalänk
Medlem
Skrivet av CyberVillain:

Faktum är att den där formen av kommentar är inte helt ovanligt tex

//normalize the heading of player
Var normalizedHeading = heading.Normalized();

Lixom ja jag kan se det

Såhär ensamt kan de se oskyldig ut men en hel klass på detta vis, fyfan

Haha ja det där är ju missbruk av kommentarer. Men har inte det mer att göra med okunskapen att skriva kod snarare än kommentarer?

Till exempel så finns det ju någon oskriven regel(?) som säger att alla namn på bool/boolean (eller logiska typer med 1/0 eller true/false utfall) bör börja på ett verb. På engelskan blir det is och has/have. Så man får då funktioner och variabler som heter: isUser(), isLocked, hasTickrate, o.s.v.

Så likt ditt exempel så får man:

// Check if server is running and has a tick rate. <= Brutalt onödig kommentar if(isRunning == true && hasTickrate == true) { code... } eller... // Check if server is running and has a tick rate. <= OK kommentar, men dålig kod if(system == true && tick == true) { code... }

I det fallet så tror jag det har mer med att man inte är så haj på att skriva lättläst kod, snarare än att man gillar att skriva kommentarer. Då försöker man täppa till den biten som är svårläst kod med kommentarer, och till slut är halva filen fylld med kommentarer. Eller så är man själv osäker och försöker förtydliga koden för sig själv. Det är vad jag tror men kan ha fel

Permalänk
Medlem

Att bara juniora utvecklare skulle använda kommentarer är komplett bullshit. Självklart ska man skriva självdokumenterande kod, och kommentarer som inte beskriver mer än vad koden själv beskriver är såklart onödiga, men det finns massor av situationer som kommentarer är riktigt bra att ha, speciellt i språk som tex. Java där IDE'er hanterar kommentarer som Javadoc och visar dessa när man mouse-over'ar metoder etc, ett par exempel:

1. Dokumentation för klasser och interfaces som det är tanken att andra utvecklare ska använda. Det är så sjukt mycket smidigare att ha det direkt i koden istället för på något extern ställe eftersom ens IDE kan hjälpa en att få upp det så snabbt. Snabbt exempel plockat från Google's Gson lib i Java:

/** * This method deserializes the specified Json into an object of the specified class. It is not * suitable to use if the specified class is a generic type since it will not have the generic * type information because of the Type Erasure feature of Java. Therefore, this method should not * be used if the desired type is a generic type. Note that this method works fine if the any of * the fields of the specified object are generics, just the object itself should not be a * generic type. For the cases when the object is of generic type, invoke * {@link #fromJson(String, Type)}. If you have the Json in a {@link Reader} instead of * a String, use {@link #fromJson(Reader, Class)} instead. * * @param <T> the type of the desired object * @param json the string from which the object is to be deserialized * @param classOfT the class of T * @return an object of type T from the string. Returns {@code null} if {@code json} is {@code null}. * @throws JsonSyntaxException if json is not a valid representation for an object of type * classOfT */ public <T> T fromJson(String json, Class<T> classOfT) throws JsonSyntaxException { Object object = fromJson(json, (Type) classOfT); return Primitives.wrap(classOfT).cast(object); }

Exempel på hur Eclipse visar detta när man mouse-over'ar respektive vid code completion:

2. Omvandling av enheter för att det snabbare ska gå att förstå av en människa:

private static final int SLEEP_DURATION_MS = 1000 * 60 * 60; // 1 hour

3. Förklaring för deprecated metoder och vad som ska användas istället:

/** * @deprecated Use the {@link #getFullName() getFullName} method instead. */ @Deprecated public String getName() { return this.firstName + " " + this.surname; }

4. Förklara design-val som är för komplexa att förklara genom koden i sig, och som inte är självklara av att bara titta på koden:

public UnitData(Unit unit) { this.unitId = unit.getId(); this.owner = unit.owner; // Creating a new Position instead of just using unit's position is needed because getPosition returns a Hexagon object which is an extension of the Position class. // The Hexagon itself has a reference to the unit on it which causes a stack overflow when gson tries to serialize this object. // As such we need to create a simple Position-copy of the Hexagon only retaining its coordinates. this.position = new Position(unit.getPosition().x, unit.getPosition().y); this.hitpoints = unit.hitpoints; }

Visa signatur

Intel i7-7700k @ 4.9Ghz - Noctua NH-U12P SE2 - MSI GTX 1070 Armor OC - AsRock Z270 Extreme4 - G.Skill Ripjaws V DDR4 3200MHz CL16 2x8GB - Corsair RM750x 750W - Samsung 970 EVO 500GB - Acer Predator X34 - Silverstone RV02-E - Asus Xonar Essence STX II 7.1 - Mionix Naos 8200 - Corsair Gaming MM400 - Das Keyboard 4 Ultimate MX Brown - Beyerdynamic DT990 Pro 250 Ohm - Antlion ModMic 4.0 Unidirectional