|
Crazy RRRussian posted:Acronyms in variable/function/class names piss me off too. I would rather have verbose names that are very descriptive than have to remember particular shortening of it. Although there is something to be said about long names that are still loving confusing and too long. It really depends on the acronym, TBH. Certainly, I would hate to see a HyperTextMarkupLanguageParser class.
|
# ¿ Aug 6, 2010 01:47 |
|
|
# ¿ May 10, 2024 00:01 |
|
Man, every time I look at that code, I see something new that's wrong with it
|
# ¿ Aug 27, 2010 11:49 |
|
king_kilr posted:If you think that's a coding horror, your codebase is probably ok. I can think of a totally valid reason for that. The Color class isn't under your control and features general color management things, for your app you want to have a consistant UI, and you're starting with their definitions of what constitutes DARK GREEN, but that might be changed in the future. No, actually, it makes about as much sense as: code:
code:
|
# ¿ Aug 28, 2010 01:51 |
|
Janin posted:it's a lot easier for some picky boss to say "can you make the buttons a bit darker" than to redefine the english language Then it should be labelled something like BUTTON_COLOR instead. ...do you write code like this yourself and are trying to defend it, or something?
|
# ¿ Aug 29, 2010 04:04 |
|
Jonnty posted:It's not particularly hard to imagine being instructed to "make it dark green", and using that so it can be easily changed in case that isn't the "right" dark green. It might have made more sense to put it under BUTTON_COLOUR or whatever, but for all we know it then actually is - as well as LABEL_COLOR and LINE_COLOR and BORDER_COLOR and ten other ones like it. Then, as I suggested before, we have UI_PRIMARY_COLOR or similar. All the benefits of COLOR_DARK_GREEN, but even more flexible for if you don't want it to be dark green any more!
|
# ¿ Aug 29, 2010 05:14 |
|
Regexes are actually a pretty good idea for this simple validation. Honestly, return str ~= /^\d+$/ is a much more clear and legible way of expressing "this should consist solely of digits", and return str ~= !^(\d{2})/(\d{2})/\d{4}$! and int($1) < 32 and int($2) < 13 is a much better way of expressing that CheckDate thingy. They're still simpler and clearer even after translating them to a language that isn't so straightforward with regards to regex matching. Of course, TryParse is really the better way of handling it. You can even use the parsed result as an out parameter, since you know the calling code is probably immediately going to parse it once you tell it it's good.
|
# ¿ Aug 31, 2010 14:26 |
|
Lumpy posted:Huh? Because the kind of person who double-pastes and doesn't notice or correct it is also the kind of person who is sloppy in other areas of their code.
|
# ¿ Sep 8, 2010 00:27 |
|
Jonnty posted:Well, since they didn't post any other horrors, I guess that wasn't the case here? Alternatively, they're in core business code that would be a fireable offence if you disclosed to the internet at large, and the poster didn't have the time to go through and anonymize it properly.
|
# ¿ Sep 8, 2010 00:48 |
|
Jonnty posted:..so he got the weakest example he could find and blew it out of all proportion. Maybe he couldn't tell which of the other WTF-y code was his and which was the other developers, so picked something he knew he didn't write?
|
# ¿ Sep 8, 2010 02:14 |
|
Zombywuf posted:Tell me, how does this distinguish file does not exist, file is a directory, file is not readable and (my personal favorite) EAGAIN. The point is, you don't really need to distinguish them. In most cases, your resolution will be "specify a valid file, dummy". The real problem is that you need to address all of them somewhere, so you can either explicitly check for them before opening the file (and then duplicate it in the exception logic in case it changes between the check and the actual access), or you can just try it and if it doesn't work, figure out how to deal with it then. Actually, the parenthetical statement is another important part. You have to write that exception logic anyway. Why not just skip the initial checks and deal with anything that goes wrong, when it actually goes wrong?
|
# ¿ Sep 8, 2010 11:34 |
|
Zombywuf posted:I'm going to take it from that that you don't know what EAGAIN means. I'm going to take it from that that you don't know what "most" means.
|
# ¿ Sep 8, 2010 13:33 |
|
OddObserver posted:I am pretty sure it's normally a good design practice for the sensible behavior to be default. Perl is designed so that common tasks can be achieved really easily, even if it results in unintuitive behaviour when taken out of context. So in this case, instead of being erroring out when you compare a string to a number, it converts the string to a number and then compares them. If you want a string-based comparison, convert the number to a string and then compare. Perl also assumes that the programmer knows what they're doing - if you convert a string that is only partially numeric to a number, it converts the numeric part and ignores the rest. If you want to do something different if the string is not just a number, explicitly test for that.
|
# ¿ Sep 26, 2010 00:45 |
|
Internet Janitor posted:Scaevolus: Maybe I'm the coding horror here, but that could be a lot worse. Assuming all the settings are already stored in a single object, that seems like a halfway reasonable way to serialize and deserialize them without worring about breaking everything when you add a field. The main problem would appear to be a failure to organize the data with any kind of heirarchy. Well, first of all, there's this line: code:
|
# ¿ Nov 14, 2010 21:19 |
|
Incoherence posted:Because it's usually something like Probably, but it's even easier to do code:
|
# ¿ Dec 1, 2010 20:55 |
|
tef posted:The weird bit I think it's like Java developers claiming that anonymous inner classes are "useful".
|
# ¿ Dec 12, 2010 05:07 |
|
ShoulderDaemon posted:For most hash constructions, you can amortize the costs of a changing suffix more readily than a changing prefix, meaning that you can take a dictionary of unsalted hashes for common passwords and cheaply transform it to a dictionary of suffix-salted hashes for common passwords, allowing more effective attacks against databases of accounts. It looks to me like the username is taking the place of a nonconstant prefix.
|
# ¿ Dec 18, 2010 03:25 |
|
Is the first thing that gets done to the result of that query a split on `~'?
|
# ¿ Mar 11, 2011 22:52 |
|
yaoi prophet posted:Whoah, this language does DWIM on English as well?
|
# ¿ May 11, 2011 22:40 |
|
Incoherence posted:As usual, this is sort of a good idea in theory (it keeps you from forgetting to clean up after yourself before returning in languages/situations where that matters, at the possible cost of making your logic harder to follow), but eventually everyone just sort of forgets the tradeoff part of it and it gets upgraded into a Law of Programming. Honestly something like the following isn't too bad if you can't have automatic cleanup for some reason: code:
|
# ¿ May 19, 2011 10:37 |
|
Zombywuf posted:HTML has lists, sets and dictionaries. It also has a bunch of other stuff like semantically marked up hyperlinks, what more could you need? Any setup where the structure of data is inherently tied up and munged in with its presentation is pretty sucky. It basically means you have to choose between presenting well-structure data for the benefit of automated systems, or well-presented data for the benefit of humans looking at it, and it's a right pain in the rear end to get both.
|
# ¿ Jun 5, 2011 15:20 |
|
Wheany posted:already-hashed user.getPassword(). Unfortunately, I'm afraid that either: 1. They're not hashing passwords, or 2. That method is poorly-named. And as much as I'm hoping it's 2, I'd have to put my money on it being 1.
|
# ¿ Jun 21, 2011 08:12 |
|
Wheany posted:Well what does encryptAndSave(user, newPassword); do? Reversible encryption.
|
# ¿ Jun 21, 2011 09:57 |
|
Considering that sleepsort is just insertion sort with a whole lot of system call overhead chucked in...
|
# ¿ Jun 25, 2011 03:54 |
|
Milotic posted:but the first call to GetAction is with a value of 1, and not 0 as you would initially intuit. It's the whole lambda scoping thing. Lambdas close over variables, not values.
|
# ¿ Jul 8, 2011 04:02 |
|
nielsm posted:Evil, but I see how it kinda makes sense. It allows you to have persistent, modifiable state in a lambda, which you you either can't or it's-a-real-pain-to-do otherwise. The obvious "toy example" is a lambda which tracks how many times it's been called, but there are some actual useful uses for it. For example, we could implement a PRNG as so (largely psuedocode): code:
|
# ¿ Jul 8, 2011 05:29 |
|
Scaevolus posted:Consistent coding style for "readability and maintenance purposes" is comical considering the developers have to work with zend-guard obfuscated code. Who wants to bet that they've actually lost the original unobfuscated source?
|
# ¿ Jul 28, 2011 03:39 |
|
Comic Sans 4 lyfe
|
# ¿ Jul 31, 2011 00:46 |
|
MEAT TREAT posted:Seriously what the gently caress is an aliasing violation? I tried looking it up, but the examples I saw didn't make any sense. Is that something that you C guys have to deal with constantly? Basically "aliasing" is when you have one location that's referred to by multiple names. If you assume that anything at all can be aliased to anything else in the current scope, then that really limits what optimizations you can do - you have to actually write everything to memory before you read through a pointer, for example. So for performance, the compiler is allowed to assume that in most cases there is no aliasing. If there actually is aliasing when the compiler assumes there isn't, then you can run into some problems with your reads getting stale values and the like.
|
# ¿ Aug 11, 2011 03:21 |
|
qntm posted:
Wait, what's the horror? Two entirely separate objects are nonequal, that's fine. Do a reference assignment so that both are referencing the same object, and then they're equal (as they should be)? PHP has enough horrors as it is, you don't really need to make up more.
|
# ¿ Aug 11, 2011 15:08 |
|
1337JiveTurkey posted:Implicit casts are functions from one type to another. If I write foo = 2 + "2" or foo = "2" + 2 then depending on the language, foo might equal 4 or "22" (or both depending on the order of the operands). Either I'm terrible at math or that is the worst violation of the Liskov Substitution Principle I have ever seen. If it's consistent within a language, then there's no problem? Unless you were wanting to talk about the principle of Least Surprise instead of LSP, I guess. Alternatively you could use a language that doesn't use the exact same operator for two completely different operations.
|
# ¿ Aug 12, 2011 06:30 |
|
Janin posted:Not many languages pass that test; for example, concatenation and addition are just as different, yet "a" + "b" isn't a type error. Depends on the language - Perl wouldn't be doing a string concatenation there, for example. When it comes to strongly-typed languages "based on the type of the left-hand operand" is a perfectly fine solution - but for a loosely typed language, overloading a single operator for two conceptually different things is a bad idea.
|
# ¿ Aug 12, 2011 06:47 |
|
nielsm posted:If two objects with the same interface have different actual operations performed by otherwise identical calls, then they are of different types. Does that make the empty string (that is, the string that returns true when you call isEmpty()) of a different type to any other string? They do have quite distinct behaviour in that regard.
|
# ¿ Aug 13, 2011 01:23 |
|
That sure is some pretty, pretty, HTML.
|
# ¿ Aug 18, 2011 07:12 |
|
See this is why typed enumerations are a good thing.
|
# ¿ Aug 22, 2011 08:02 |
|
BonzoESC posted:Except for the forums mangling your indentation, that looks pretty much par for the course for jQuery. code:
|
# ¿ Sep 3, 2011 00:48 |
|
Haystack posted:Javascript's ternary syntax is var return_value = test ? expression1 : expression2. So JediGandalf's code would return "pct" if downType=$('#rdoPercentage').val() returned "pct", or "fixed" if otherwise. Right. But my point is that there's only one HTML element with an id of #rdoPercentage, and that always has the value "pct". Which is why I was asking about jQuery, not javascript.
|
# ¿ Sep 3, 2011 03:00 |
|
"Design patterns" are basically means of working around deficiencies in a language, and most uses of goto are no exception. - Early-days uses of goto were workarounds for a lack of proper structured-programming constructs. This deficiency has been corrected in many modern languages. - Using goto to help implement single-point-of-return is generally a workaround for a language not having having a mechanism for scope-based resource lifetimes - some languages (e.g. C++, anything with proper try-finally blocks) have this, but others don't, so using goto in this manner could be alright if your language doesn't have a better way of doing it. - Using goto to break out of nested loops is a workaround for not otherwise being able to interact with control flow elements that aren't "the element I am directly inside of" or "the entire function I am part of". Goto is bad, but sometimes it's better than all the alternatives, and when that's the case it usually suggests a deficiency in the language.
|
# ¿ Sep 8, 2011 09:29 |
|
Aleksei Vasiliev posted:URL a = new URL("http://stackoverflow.com"); You know what's awesome about this? If the machine you're running on has no DNS, your calls to equals will hang the thread for a second or two while the name lookups time out.
|
# ¿ Sep 15, 2011 09:39 |
|
I would guess it's the fact that the + operator is overloaded for both addition and string concatenation, which makes the operator not associative in certain combinations of types. (Foo + (string + integer)) [the first snippet] does one thing, while ((Foo + string) + integer) [the second one] does it differently.
|
# ¿ Sep 16, 2011 04:23 |
|
|
# ¿ May 10, 2024 00:01 |
|
Wheany posted:Yes, the init function has one eval in the middle of the for some reason. It appears to be an (ugly and terrible) workaround for how this gets evaluated in Javascript, by "baking in" the value of this._elementId when the event is created rather than having it be resolved when the event runs. Of course there are so many better ways of doing it but it is necessary to do something there to get around Javascript's this-fuckery.
|
# ¿ Sep 16, 2011 13:49 |