Talk:1513: Code Quality

Explain xkcd: It's 'cause you're dumb.
Revision as of 16:52, 17 April 2015 by (talk)
Jump to: navigation, search

On the bright side, I now have a new array of phrases to keep me sane while doing code reviews... 05:47, 17 April 2015 (UTC)

I think the emojis were referring to swift where you can use emojis as variables. (talk) 05:53, 17 April 2015‎ (please sign your comments with ~~~~)

Could we get a link for the Apple language? 06:09, 17 April 2015 (UTC)

This is going on our OneNote at work. It totally made my day Jdluk (talk) 08:06, 17 April 2015 (UTC)

Yet another reason I'm glad I'm not a coder anymore (went back to hardware design . . . with NO style guidelines ;^) (talk) (please sign your comments with ~~~~)

The description reads as if camelCase is part of every style. There are styles containing camelCase, but not all of them do. Also, different styles contain different rules, so following one specific style guide will be in conflict with others, therefore it's not necessary good idea: unless you program in team which agreed upon which style to use, it may be better if you don't worry to much to follow style exactly. On the other hand, if Ponytail's similes are accurate, Cueball is likely to discover lot of basic rules which will make the program easier to read even for him.

For example, there are lot of styles for Indenting alone, but most readability comes from the basic idea to indent code according to block it belongs to. -- Hkmaly (talk) 12:02, 17 April 2015 (UTC)

Out of curiosity I tried using 😭 as a variable name in Common Lisp. It works in SBCL, but fails in CLISP. 12:19, 17 April 2015 (UTC)

I really wish I knew anything about coding so I could contribute, but my 8th grade HTML class didn't help me that much. The Goyim speaks (talk) 12:50, 17 April 2015 (UTC)

The cruel person might point out that HTML isn't even 'coding'. (It's markup, for the most part, unless you're dabbling in DHTML or some of the latest bastardisations that have crept into HTML5.) But you will of course know the bit where you get "Hang on, why is that table element on the wrong line/off the end of the line/short of the end/outside the table, even?" and how it makes it easier to use a new-line and indentation scheme at appropriate places (and a logical policy of which lines not to split) so that errors like unaccounted-for COLSPANs and bad tag-pairing can be tracked down easily.
So it is with code. Liken it to obfuscation of HTML formatting (including using non-sensical, albeit consistent in themselves, id and name tags for the CSS to hang off of) can be employed deliberately (to prevent easy human readability/backformation) or incidentally (because it's created by a server-side/CMS generating script that hasn't been told to try to add useful whitespace). Moreso when it comes to <script> insertions (often deliberately obfuscated to single-letter variables, minimal whitespace and no line-feeds, perhaps in an misplaced attempt to enact 'security through obscurity', but of course that then is code. Arguably.
One of the aims could be to reduce the size of the 'code' (even when that's Markup), which is laudible given how much over-padded stuff you can get (I don't know if Microsoft Word's "Save as HTML"/whatever is currently as bad as it was in the early days, but even a web-page with just "Hello World" was chockablock full of formatting information that it never even bothered to ask if were necessary), but unless you absolutely do not need (or do not want!) people to read the code, both people and auto-generation scripts should attempt to impart visual elegance. IMO! 16:52, 17 April 2015 (UTC)