Aan de andere kant, ik heb nu een nieuwe reeks zinnen om me gezond te houden terwijl ik code reviews doe… 108.162.249.162 05:47, 17 April 2015 (UTC)

Ik denk dat de emoji’s betrekking hadden op swift waar je emoji’s als variabelen kunt gebruiken. 108.162.250.168 (talk) 05:53, 17 April 2015 (onderteken uw opmerkingen met ~~~~)

Zouden we een link kunnen krijgen voor de Apple taal? 108.162.249.162 06:09, 17 April 2015 (UTC)

Dit gaat op onze OneNote op het werk. It totally made my day Jdluk (talk) 08:06, 17 April 2015 (UTC)

Nog een reden waarom ik blij ben dat ik geen coder meer ben (ging terug naar hardware design . . met GEEN stijlrichtlijnen ;^) 173.245.56.182 (talk) (onderteken uw opmerkingen met ~~~~)

De beschrijving leest alsof camelCase onderdeel is van elke stijl. Er zijn stijlen die camelCase bevatten, maar niet allemaal. Ook bevatten verschillende stijlen verschillende regels, dus het volgen van een specifieke stijlgids zal in strijd zijn met andere, daarom is het niet noodzakelijk een goed idee: tenzij je programmeert in een team dat heeft afgesproken welke stijl te gebruiken, is het misschien beter als je je niet te veel zorgen maakt om de stijl exact te volgen. Aan de andere kant, als Ponytail’s simulaties juist zijn, zal Cueball waarschijnlijk veel basis regels ontdekken die het programma makkelijker leesbaar maken, zelfs voor hem.

Er zijn bijvoorbeeld veel stijlen voor inspringen alleen, maar de meeste leesbaarheid komt van het basis idee om code te laten inspringen volgens het blok waar het bij hoort. — Hkmaly (talk) 12:02, 17 April 2015 (UTC)

Uit nieuwsgierigheid heb ik geprobeerd 😭 te gebruiken als variabelenaam in Common Lisp. Het werkt in SBCL, maar faalt in CLISP. 108.162.221.112 12:19, 17 April 2015 (UTC)

Ik wou echt dat ik iets van coderen wist, zodat ik kon bijdragen, maar mijn 8e klas HTML-les heeft me niet zo veel geholpen. The Goyim speaks (talk) 12:50, 17 April 2015 (UTC)

De wrede persoon zou erop kunnen wijzen dat HTML niet eens ‘coderen’ is. (Het is markup, voor het grootste deel, tenzij je je bezighoudt met DHTML of enkele van de nieuwste bastardisaties die in HTML5 zijn geslopen). Maar je kent natuurlijk wel het stukje waar je te horen krijgt “Wacht even, waarom staat dat tabelelement op de verkeerde regel/aan het eind van de regel/te kort voor het eind/buiten de tabel, zelfs?” en hoe het makkelijker is om op de juiste plaatsen een nieuwe regel en inspringing te gebruiken (en een logisch beleid van welke regels niet gesplitst mogen worden) zodat fouten zoals niet verantwoorde COLSPANs en slechte tag-pairing gemakkelijk opgespoord kunnen worden. Zo is het ook met code. Vergelijk het met vertroebeling van HTML opmaak (inclusief het gebruik van onzinnige, zij het op zichzelf consistente, id en name tags voor de CSS om aan op te hangen) kan opzettelijk worden toegepast (om gemakkelijke menselijke leesbaarheid/achtergrondvorming te voorkomen) of incidenteel (omdat het wordt gemaakt door een server-side/CMS genererend script dat niet is verteld om te proberen nuttige witruimte toe te voegen). Hetzelfde geldt voor <script>-invoegsels (vaak opzettelijk versluierd tot eenlettergrepige variabelen, minimale witruimte en geen line-feeds, misschien in een misplaatste poging om ‘veiligheid door onduidelijkheid’ te bewerkstelligen, maar dat is dan natuurlijk code. Ongetwijfeld. Eén van de doelstellingen zou kunnen zijn om de omvang van de “code” te verminderen (zelfs als dat Markup is), wat prijzenswaardig is gezien de hoeveelheid overvolle dingen die je kunt krijgen (ik weet niet of Microsoft Word’s “Opslaan als HTML”/whatever tegenwoordig net zo slecht is als in de begindagen, maar zelfs een web-pagina met alleen maar “Hallo Wereld” zat boordevol opmaak-informatie die niet eens de moeite nam om te vragen of ze nodig waren), maar tenzij je absoluut niet wilt (of niet nodig hebt!) dat mensen de code lezen, zouden zowel mensen als auto-generatie scripts moeten proberen visuele elegantie mee te geven. IMO! 141.101.98.192 16:52, 17 April 2015 (UTC)

Voegt de tweede alinea van de uitleg, beginnend met “Een veelgebruikte techniek,” iets toe om de strip uit te leggen? Ik zie het niet, maar ik kom dan ook uit het tijdperk van COBOL. Miamiclay (talk) 19:54, 18 April 2015 (UTC)

Ik zou een herschrijving willen voorstellen naar iets in de trant van “Een veelvoorkomend patroon bij autodidactische programmeurs…”. Wat betreft de noodzaak van de alinea, ik heb het gevoel dat het helpt om uit te leggen waar sommige programmeurs met slechte (of een totaal gebrek aan) werknormen vandaan komen. Het is het soort programmeurs dat gewend is om codevoorbeelden te kopiëren en te plakken en ze net zo lang te bewerken tot het doet wat zij willen, onbewust een afschuwelijk niveau van ongelijkheid introducerend in de code, alsmede alle verstandige codeerstandaarden en ontwerppatronen negerend. Ik kan uit ervaring spreken dat dergelijk gedrag bestaat, maar dat de meeste van die mensen ofwel snel stoppen met programmeren ofwel na verloop van tijd leren om de juiste standaarden aan te passen. Ik ben blij te kunnen zeggen dat ik tot de laatste groep behoor. – Erim Secla 141.101.79.67 08:02, 19 april 2015 (UTC)

Hoe weten we dat Agile en SaaS hier relevant voor zijn? 173.245.50.84 17:38, 19 april 2015 (UTC)

Het heeft geen relatie, en bovendien denkt degene die software-as-a-service heeft toegevoegd waarschijnlijk dat het iets anders betekent dan wat het doet Spongebog (talk) 19:30, 19 april 2015 (UTC)Het kan zelfs spam zijn geweest of een zelfpromotielink. Spongebog (talk) 19:32, 19 april 2015 (UTC) Emoji

IMHO is de discussie over emoji er een beetje naast. Emoji zijn specifiek de grafische voorstellingen (😢), niet de op tekst gebaseerde smileys (T_T). En de zinnen over taalondersteuning gebruiken dubbele negatieven, wat erg verwarrend is, en waarschijnlijk moet vermelden dat Javascript dit niet lijkt toe te laten. (In mijn testen toch.) Stevage (talk) 14:17, 20 April 2015 (UTC)

Ik ben het eens. Emoticons en Emoji zijn twee verschillende dingen.–17jiangz1 (talk) 14:56, 20 April 2015 (UTC) Kunnen we onderscheid maken tussen grafische emoji en karaktergebaseerde unicode emoji? Het verschil is dat de ene via een of andere vorm van markup code (client-side of server-side, ofwel wanneer het denkt een expliciete emoticon/etc string te hebben zoals “:)” of een gecodeerde uitspraak tegenkomt zoals “:lol:”) in de normale tekst wordt gewisseld terwijl de andere er al is zonder dat er extra beeldbytes nodig zijn. Behalve dan misschien het downloaden van font-bestanden, natuurlijk. Ik neem aan dat het bovenstaande (😢) het laatste is, hoewel dat voor mij een onuitspreekbaar teken is, net als de meeste voorbeelden op deze pagina, en ik neem aan dat ik een of ander nieuw lettertype moet installeren om het te kunnen zien op de browsers waarmee ik het geprobeerd heb. Ik heb echter wel ☺ en ☻ tot mijn beschikking. Dus ik kan in ieder geval emote op de manier van Dwarf Fortress (die, ironisch genoeg, gebruik maakt van afbeeldingen van de originele personages). 141.101.99.69 17:51, 21 April 2015 (UTC)

Ew niet-Emoji code. Dit is de 21e eeuw, get updated: https://github.com/emj-lang Natuurlijke talen ftw! Geen this_is_a_variable_that_contains_the_number_of_xkcds_ever_posted meer! 108.162.210.246 21:18, 5 juni 2015 (UTC)

On a tangential note, I once tried to install a decompiler into IntelliJ by copying and pasting a folder (not realizing it was the same decompiler IntelliJ already shipped with) and run it on Minecraft. Het gaf alle variabelen en functies een ☃ naam. Promethean (talk) 22:28, 17 juni 2015 (UTC)

Toegevoegde info over code kwaliteit 3 141.101.104.215 03:43, 7 mei 2017 (UTC)