|
Sulla-Marius 88 posted:Content: The guy next to me is checking out pictures of kitchens and couches and bathrooms instead of fixing the bugs he's made.
|
# ? Apr 9, 2014 19:29 |
|
|
# ? May 27, 2024 21:17 |
|
If the guy who wrote the feature you're fixing is on standby, I'd consider that an invitation to start delegating small, routine parts of the work to him.
|
# ? Apr 9, 2014 19:48 |
|
eithedog posted:Funny you say that. In here people tend to comment stuff out, but unfortunately commenting might happen on multiple levels. First, there's PHP level (/* */), then there's template level ({* *}), then, there's HTML level (<!-- -->). Guess what do I deal with? I was editing a fairly important (PHP) file at a place I used to work - it did routing, IIRC - and noticed an unclosed comment at the bottom. Thought that was pretty odd/lazy of someone so I deleted it and reloaded to a big fat parse error. The comment was closed in the including file. I might be misremembering. It could have been an HTML comment, but that was the level of fuckery I had to deal with.
|
# ? Apr 9, 2014 20:54 |
Munkeymon posted:I was editing a fairly important (PHP) file at a place I used to work - it did routing, IIRC - and noticed an unclosed comment at the bottom. Thought that was pretty odd/lazy of someone so I deleted it and reloaded to a big fat parse error. The comment was closed in the including file. That's fantastic. That's also the similar sort of stuff I expect from this, so once I commented the DB calls out (I'm too scared to delete it) I sent an email around to everyone involved going "Hey so.. I found these... if.. if anybody still needs these... just let me know...".
|
|
# ? Apr 9, 2014 22:34 |
|
QuarkJets posted:Vectors are for that, but you can use them for static collections, too. Vectors use a tiny bit more memory, but this tradeoff is worth all of the extra flexibility in nearly all cases.
|
# ? Apr 9, 2014 23:08 |
|
Munkeymon posted:I was editing a fairly important (PHP) file at a place I used to work - it did routing, IIRC - and noticed an unclosed comment at the bottom. Thought that was pretty odd/lazy of someone so I deleted it and reloaded to a big fat parse error. The comment was closed in the including file. I had the same issue on my first job, but it was asp. Classic asp.
|
# ? Apr 9, 2014 23:58 |
|
Sulla-Marius 88 posted:That's fantastic. That's also the similar sort of stuff I expect from this, so once I commented the DB calls out (I'm too scared to delete it) I sent an email around to everyone involved going "Hey so.. I found these... if.. if anybody still needs these... just let me know...". It's in source control, right? That buys you two things. 1, you are free to delete it. 2, there is a blame tool and you can go ask the guy what the implications of removing them are. Until they are either deleted or left in and you know why, you haven't done your job you've only added to the horror.
|
# ? Apr 10, 2014 01:17 |
|
Sulla-Marius 88 posted:That's fantastic. That's also the similar sort of stuff I expect from this, so once I commented the DB calls out (I'm too scared to delete it) I sent an email around to everyone involved going "Hey so.. I found these... if.. if anybody still needs these... just let me know...". Yes, remove it. Source control is for versioning your code, not comments. In my world, commented out chunks of code are grounds for a code review failure.
|
# ? Apr 10, 2014 01:58 |
|
Dren posted:It's in source control, right? That buys you two things. 1, you are free to delete it. 2, there is a blame tool and you can go ask the guy what the implications of removing them are. Until they are either deleted or left in and you know why, you haven't done your job you've only added to the horror. It's too bad there aren't any blame tools that say "dude deleted some code that used to be here", since that's often pretty relevant in my horror-chasing.
|
# ? Apr 10, 2014 02:08 |
|
Perforce's time-lapse view does a decent job of it.
|
# ? Apr 10, 2014 02:17 |
|
Subjunctive posted:It's too bad there aren't any blame tools that say "dude deleted some code that used to be here", since that's often pretty relevant in my horror-chasing. git log accepts a path spec. so you can do "git log foo.c" or "git log ." Or "git whatchanged foo.c", which will show the diffs too.
|
# ? Apr 10, 2014 03:00 |
|
Old news no doubt but I just found out that there are people who earnestly advocate something called "semicolon-free JavaScript", which is where you write JavaScript and allow automatic semicolon insertion to decide where your statements end.
|
# ? Apr 10, 2014 03:13 |
|
Hammerite posted:Old news no doubt but I just found out that there are people who earnestly advocate something called "semicolon-free JavaScript", which is where you write JavaScript and allow automatic semicolon insertion to decide where your statements end. Thats the correct way to write javascript.
|
# ? Apr 10, 2014 03:29 |
|
No it's not. jfc why is web development in loving opposite land?
|
# ? Apr 10, 2014 03:33 |
|
Sinestro posted:No it's not. jfc why is web development in loving opposite land? no barrier to entry? edit: eh, that's not fair really, and is just me being old and crotchety. Seriously though, it's probably more that the accessibility of the web sort of pushed development towards tools that try to "figure out" what the programmer wanted (semicolon insertion, PHP as a whole, etc), which combined with non-obvious warning and error failure modes leads inexperienced developers to flock to the platform since it is "easier" and "modern", which feeds back to the beginning and creates a powder keg of ineptitude waiting for someone to strike an sql-injection match. edit 2: to expand on that a bit, it's a few different things: 1) existing web tools such as javascript and php remove *ANY* barrier to entry, which isn't a bad thing but it does bring in a lot of people with no formal or doctrinal education. 2) the failure mode of a ton of web apps, platforms, etc is all in console (hidden by default) or server logs (often inaccessible entirely) which masks best-practice warning messages and makes debugging complicated situations even more difficult than it otherwise would be. Additionally, this means a lot of "accidentally correct" code with major flaws or assumptions seems "correct" since all of its various warnings, type coercions, etc are hidden. 3) a lot of web development platforms and such strive to be "magic" or "Just do the right thing" (this is your semicolon insertion, loose equality, hilarious type coercions, etc), which leads to a lot of code that has major edge case failures that an inexperienced programmer won't expect or know to watch for. 4) an entrenched culture that rewards copy-paste programming and encourages programming by coincidence allows errors from issues 1 through 3 to breed, mutate, and propagate through the years. teamdest fucked around with this message at 03:56 on Apr 10, 2014 |
# ? Apr 10, 2014 03:40 |
|
I can't speak to most of that, but at least for JS semi insertion was originally motivated by making it work well in HTML-embedded cases. Forgetting the trailing semi in onclick="alert('hi');" was just going to be frustrating for people. Similarly missing them at the end of function bodies, one-statement <script> tags, etc. It definitely didn't scale well with JS usage, but it was hard to predict that JS would scale as far as it did (it was going to be a thing to glue together "real logic" written in Java, really.) PHP I'm sure started similarly casually, but it's *way* easier to fix a server-side language because the developer decides what version is going to run what code. With JS the user has a browser and the developer has to live with it, largely. I'm not sure why they didn't clean it up sooner; Hack shows that it's possible to improve it in a lot of ways with minimal loss of compatibility. Edit: I think those four points are bang-on. Edit edit: vvvv Hammerite posted:Looks like you don't understand JavaScript well enough, and should go read the spec so that you can understand the intricacies of automatic semicolon insertion and harness its power for yourself! (this is an actual argument employed by proponents) People who have helped write the spec make ASI errors; it's a scourge, but it's not one that's going away. Subjunctive fucked around with this message at 04:24 on Apr 10, 2014 |
# ? Apr 10, 2014 04:11 |
|
Sinestro posted:No it's not. jfc why is web development in loving opposite land? Looks like you don't understand JavaScript well enough, and should go read the spec so that you can understand the intricacies of automatic semicolon insertion and harness its power for yourself! (this is an actual argument employed by proponents)
|
# ? Apr 10, 2014 04:17 |
|
There are only two cases you really have to be worried about ASI loving up, one case you literally would never do unless you are a dumb moron, the other case occurs enough where you have to put in a semicolon if you really really want to write it that way. Otherwise no one should give a poo poo either way but people make this out to be some big deal.
|
# ? Apr 10, 2014 04:18 |
|
http://bclary.com/2004/11/07/#a-7.9.1 You see those several paragraphs of text describing the circumstances of ASI? See how much simpler it is than just putting a semicolon at the end of your statements? If you don't memorise these arcane rules and unnecessarily create situations in which to apply them then you are using the JavaScript language wrong
|
# ? Apr 10, 2014 04:28 |
|
Strong Sauce posted:Thats the correct way to write javascript. If you want to prevent the noobs and/or those not in to self-harm from being able to contribute to your code, the correct answer is to follow haXe and pick a language that nobody uses. Unless there's some other benefit to swallowing that section of the spec? Sorry, "a reaffirmation of my smugness" doesn't count.
|
# ? Apr 10, 2014 04:35 |
|
The rules just boil down to this 1: don't put the return value on a separate line from the return 2: if you start a line with a parenthesis to enclose a value, prepend with a ; And there is a third rule if you somehow decide that a postfix operator on the next line is smart, in which case... Now if you're talking to someone starting out in javascript, then feel free to tell them to just use semicolons rather than explain what asi is. If a team decides they'd rather not use semicolons and they know the risks, who cares?
|
# ? Apr 10, 2014 04:37 |
|
QuarkJets posted:Vectors are for that, but you can use them for static collections, too. Vectors use a tiny bit more memory, but this tradeoff is worth all of the extra flexibility in nearly all cases. Isn't a vector basically "a chunk of continuous storage" + "a little bit of bookkeeping data"? You can memcpy into them if you do it right.
|
# ? Apr 10, 2014 04:45 |
|
Strong Sauce posted:The rules just boil down to this Rule 1 also applies to break, continue, throw and in Harmony yield and module. Most often ASI issues bite people due to program transformation: the bootstrap-vs-JSMin slapfight of a couple of years ago, JS files being concatenated and the effect of the last line in one file being changed by the first line in the next file, that sort of thing. You can definitely operate safely without semicolons, but it requires a lot more reasoning about possible other interpretations of the source tokens to do so. People of @fat's calibre manage; I'm not of that calibre, even with 8+ years of JS behind me.
|
# ? Apr 10, 2014 04:49 |
|
Strong Sauce posted:The rules just boil down to this "The rules just boil down to this: *forgets part of the rules*" is perhaps not as convincing an argument as you think. Obviously I don't care about "a team", nor do I care about their understanding of "the risks" (unless I'm on your team). That's a far cry from "the correct way to write JavaScript". Just trying to set an example for the kids. (Aside: do you think ASI is a good idea? A worthwhile feature in a programming language? I don't ask to try to convince you away from it, I'm wondering if I've come across someone who holds these positions.)
|
# ? Apr 10, 2014 05:40 |
|
Subjunctive posted:I can't speak to most of that, but at least for JS semi insertion was originally motivated by making it work well in HTML-embedded cases. Forgetting the trailing semi in onclick="alert('hi');" was just going to be frustrating for people. Similarly missing them at the end of function bodies, one-statement <script> tags, etc. It definitely didn't scale well with JS usage, but it was hard to predict that JS would scale as far as it did (it was going to be a thing to glue together "real logic" written in Java, really.)
|
# ? Apr 10, 2014 06:41 |
|
"JavaScript is a scripting language where semicolons as statement terminators are optional, as in: op·tion·al (adjective) Available to be chosen but not obligatory" (I actually lean towards this style personally, but I think the article is, as it were, a bike-shedding horror.)
|
# ? Apr 10, 2014 08:11 |
|
"Easy solution: when a line starts with parenthesis, prepend a semicolon to it. ;(d + e).print() This might not be elegant, but does the job. Michaeljohn Clement elaborates on this even further: If you choose to omit semicolons where possible, my advice is to insert them immediately before the opening parenthesis or square bracket in any statement that begins with one of those tokens, or any which begins with one of the arithmetic operator tokens /, +, or - if you should happen to write such a statement. Adopt this advice as a rule and you’ll be fine." So instead of something simple, terminate all statements with a semicolon, we now prepend according to these specific rules. Gee, stuff is so much simpler now. I like whitespace as much as the next person, having learned on python, but is terminating with a semicolon really such a big deal that you'd prefer to apply more non obvious rules to your code style?
|
# ? Apr 10, 2014 08:24 |
|
I like the way he redefines what's understood by the term "minification" to attempt to prove his point. I don't understand what's so difficult or bad about terminating expressions with a semi-colon in a C-style language either. e: "only people can detect and solve software bugs, not tools" - guess someone's never heard of static analysis tools! Sure, they won't find every bug, but they can and do find some. ..btt fucked around with this message at 08:30 on Apr 10, 2014 |
# ? Apr 10, 2014 08:27 |
"I code everything in notepad in the same file without includes or OOP because there's no way in hell I'm trusting a machine to do my job for me" -- someone whose entire job is to feed instructions into a machine so that it can do the job of other people.
|
|
# ? Apr 10, 2014 08:44 |
|
I write my C and C++ using trigraphs whenever possible. The rules aren't complicated, it's a simple step before preprocessing. I mean, just memorize this brief table:pre:??= # ??( [ ??/ \ ??) ] ??' ^ ??< { ??! | ??> } ??- ~ I've never encountered a mainstream compiler that had a problem with trigraphs. Some claim it's easier or less confusing to simply use the nearly universally preferred single-character equivalents (or as I call it, "wahh this is so difficult we need -Wtrigraphs on by default"). Sure, you have to be on your toes with the occasional string literal, and it gets difficult to tell where comments begin and end, and these issues typically become obvious only at runtime. Nonetheless, this arcane feature exists and nobody uses it. It is therefore an excellent shibboleth, a rallying cry that proclaims "yes, this programming language is poo poo, but at least our team writes it in a technically admissible and largely alienating dialect; this proves that we must know what we are doing".
|
# ? Apr 10, 2014 09:40 |
|
I think optional semicolons are great because when you see somebody that thinks it makes sense to omit them or that semicolons are ugly, you'll be ready for superficialities in other opinions they hold, be it on encodings, design patterns, how to use version control systems, or radical feminism. (USER WAS PUT ON PROBATION FOR THIS POST)
|
# ? Apr 10, 2014 11:09 |
shrughes posted:I think optional semicolons are great because when you see somebody that thinks it makes sense to omit them or that semicolons are ugly, you'll be ready for superficialities in other opinions they hold, be it on encodings, design patterns, how to use version control systems, or radical feminism. Just so I haven't misinterpreted this, you're referring to the overwhelming number of socially-maladjusted sexist IT workers who for some reason can't keep their worthless opinions to themselves, right? Rather than criticising 'radical feminists' yourself..
|
|
# ? Apr 10, 2014 11:22 |
Sulla-Marius 88 posted:Just so I haven't misinterpreted this, you're referring to the overwhelming number of socially-maladjusted sexist IT workers who for some reason can't keep their worthless opinions to themselves, right? Rather than criticising 'radical feminists' yourself.. Personally, not many women are in computers. There must be a solid empirical reason for this?
|
|
# ? Apr 10, 2014 13:08 |
|
OBAMA BIN LIFTIN posted:Personally, not many women are in computers. There must be a solid empirical reason for this? Women are scary and have cooties.
|
# ? Apr 10, 2014 13:16 |
|
OBAMA BIN LIFTIN posted:Personally, not many women are in computers. There must be a solid empirical reason for this? It's because there's not enough room for a woman inside of one. They're pretty small, mostly. Edit: computers, I mean
|
# ? Apr 10, 2014 13:22 |
|
ironic sexism isn't actually less annoying
|
# ? Apr 10, 2014 13:29 |
|
There are even fewer men in computers than women because men are larger.
|
# ? Apr 10, 2014 13:30 |
|
Bongo Bill posted:There are even fewer men in computers than women because men are larger. Inside of a dog, it's too dark to read.
|
# ? Apr 10, 2014 13:37 |
|
Bongo Bill posted:It's because there's not enough room for a woman inside of one. They're pretty small, mostly. Edit: computers, I mean You'd think there would be more women in data centers, then, since they can fit.
|
# ? Apr 10, 2014 14:11 |
|
|
# ? May 27, 2024 21:17 |
|
Volmarias posted:You'd think there would be more women in data centers, then, since they can fit.
|
# ? Apr 10, 2014 14:19 |