|
kitten smoothie posted:My workflow with this is that I end up having my feature branch in which I work, then I have to have a second review branch off that where I do the rebase-squash dance. Then if there are changes I make them back in the feature branch, cherry pick that into the review branch, then do another squash to amend the bigass squashed commit. Save yourself the headache and amend the commit that you need to change.
|
# ? Feb 14, 2014 16:06 |
|
|
# ? Jun 6, 2024 10:00 |
|
Was trying to book a flight today:JavaScript code:
gently caress you AirTran. (The irony is that I changed it because my original name, "Jean-Philippe St. Pierre" confused every form. AirTran's regexp accepts '-', but not '.')
|
# ? Feb 14, 2014 16:59 |
|
Suspicious Dish posted:Was trying to book a flight today: What's the point of trying to validate names anyway? There's guaranteed to be a person with a legal name that does not fit whatever your code tests. http://www.kalzumeus.com/2010/06/17/falsehoods-programmers-believe-about-names/
|
# ? Feb 14, 2014 17:25 |
|
Sulla-Marius 88 posted:And these are the italians lucky enough to find work. What a country. In my experience, all the good ones go work abroad. Programmers in Italy usually get screwed up in one or more of the following ways:
hackbunny fucked around with this message at 17:34 on Feb 14, 2014 |
# ? Feb 14, 2014 17:32 |
Yeah the working situation definitely isn't great. I'm definitely thankful that I got a job at all (no experience or qualifications and I don't speak Italian) so I can't be too upset with the conditions that allowed me to be competitive. But I'm slackjawed at the depths of computer illiteracy of people whose jobs ostensibly involve programming. For me it's a good job (in the short term) because I'm forced to practice Italian, I'm forced to learn and practice PHP and related systems, and the pay is enough to live on but minimal enough that I'm not at risk of getting complacent. Plus I really like my boss and even my co-workers on a personal level. Just not a professional level. If we had moved to Germany or France I would have gotten a better job, but only if I'd gotten one - my French has probably fallen behind my Italian by this point. The main thing that terrifies me is just what's going to happen when we're no longer actively developing/bugfixing stuff. One of the other guys told me that he thinks we'll be here for months and months bugfixing and I didn't believe him until I saw the kind of code he was putting out and calling "done" -- it's not even functional by any legitimate analysis, he just 'bugfixes' it to where it's not producing visible error messages, and not realising that the data is wrong. So they may have actually shat us so thoroughly that I'll be stuck here dealing with these lovely clients for months. In which case I may as well have just written the whole bloody thing myself. quote:
No tech support but I was responsible for setting up all the system admin stuff on the dev server and then hand-holding the client's IT team through setup of the prod server. Thankfully I'm a legitimate employee, but I think the contract says only for this project and then it'll be reviewed -- which just means, if the business goes under and doesn't get enough work, then I won't have a job. Nothing sinister or sneaky. Sulla Faex fucked around with this message at 17:43 on Feb 14, 2014 |
|
# ? Feb 14, 2014 17:41 |
|
Feel like I should give a counterpoint as I also work for an Italian company, and while its far from perfect - low comparative pay here as well - its really not that bad. My long term colleges are all good programers, we use decent source control and have a reasonably sane process with builds on check-in and unit testing and a good QC department, separate IT etc. I wrote long term colleges before as we've had a decent amount of chancers come through who can't do poo poo, but they don't last long. Another negative is our code base has plenty of lurking horrors, but its maybe 12 years old now and they don't compare to the worst of the thread.
|
# ? Feb 14, 2014 20:30 |
|
Snapchat A Titty posted:What's the point of trying to validate names anyway? There's guaranteed to be a person with a legal name that does not fit whatever your code tests. My middle initial is U+0000
|
# ? Feb 15, 2014 22:49 |
|
qntm posted:My middle initial is U+0000
|
# ? Feb 15, 2014 22:51 |
|
Suspicious Dish posted:Dear people who care about open-source: please do not submit issues containing the pettiest garbage I've ever seen. It's not petty and these are valid criticisms/bugs. Sorry you like encouraging poor code.
|
# ? Feb 16, 2014 09:21 |
|
That Turkey Story posted:It's not petty and these are valid criticisms/bugs. Sorry you like encouraging poor code.
|
# ? Feb 16, 2014 09:35 |
|
That Turkey Story posted:It's not petty and these are valid criticisms/bugs. Sorry you like encouraging poor code.
|
# ? Feb 16, 2014 10:21 |
|
If you're going to write a bot to open issues, you should at least take a minute to have the messages be useful and informative and probably something closer to English.
|
# ? Feb 16, 2014 11:01 |
|
That Turkey Story posted:It's not petty and these are valid criticisms/bugs. Sorry you like encouraging poor code. Since you're our representative C++ guy, I'm going to ask you: do you know any compilers that treat use of a reserved identifier as undefined behavior, and do you know any bugs that can happen as a result of it? Do they compile the Linux kernel and glibc properly, both of which break those same exact rules?
|
# ? Feb 16, 2014 16:04 |
|
Isn't leading underscores reserved for the standard library, of which glibc is an implementation of?
|
# ? Feb 16, 2014 16:31 |
|
I've never seen broken English that is also extremely condescending before. First time for everything, I suppose.
|
# ? Feb 16, 2014 21:59 |
|
It's an open sores project on GitHub. If the guy has that level of technical knowledge to know what reserved IDs are, he can submit a patch to remove them. Since he's submitting it to tracking for someone else to work on, he should have made a case for it being worth the effort.
|
# ? Feb 16, 2014 22:08 |
|
It's a bot, people.
|
# ? Feb 16, 2014 22:54 |
|
Here's a coding horror: it is 2014 and Java is only now adding String.join().
|
# ? Feb 17, 2014 00:18 |
|
Suspicious Dish posted:Since you're our representative C++ guy, I'm going to ask you: do you know any compilers that treat use of a reserved identifier as undefined behavior, and do you know any bugs that can happen as a result of it? Do they compile the Linux kernel and glibc properly, both of which break those same exact rules? No compiler is going to randomly break code that uses system-reserved identifiers. The point of the rule is to allow system headers — which are included everywhere, and which there's typically somebody in charge of coordinating as a package — to create and change internal macros and declarations without worrying about breaking reasonable code. libc and the kernel's public headers are exactly who should be using the reserved namespace and therefore benefitting from this. Second-tier system headers like the C++ standard library and all the other random stuff that lands in /usr/include have some claim to this as well, because like I said before, somebody in charge of the distribution is supposed to detect stuff like "your new macro guard in <sys/types.h> completely broke anybody using <vector>." But you cannot actually expect them to roll back the new standard library while they chase down your random rude project that's flaunting the rules out of underscore envy. In other words, it's an affordance to make life massively easier for the people with maximal downstream header dependencies. If you add a library-specific prefix to your include guards like everybody knows you're supposed to, it does not really matter, but doing so also negates any reason to put stuff in the restricted namespace. rjmccall fucked around with this message at 01:07 on Feb 17, 2014 |
# ? Feb 17, 2014 01:04 |
|
Thanks, that makes sense. I agree that a define like __TYPES_H__ is bad, but so is TYPES_H, so just making our code "standards-compliant" wouldn't really improve the code quality. I don't see anything wrong with __COCKPIT_TYPES_H__. Obviously, #pragma once would be the best solution, though I'd love to hear from a compiler person if there's anything wrong with that. The argument against it the guy linked was about symlinks and the difficulty of specifying exactly how "has been included before" works. I also am very curious why it's a source of undefined behavior according to the spec, however. Is it just the only mechanism they have in the spec to say "this code may break when it clashes with the system headers"?
|
# ? Feb 17, 2014 01:13 |
|
qntm posted:Here's a coding horror: it is 2014 and Java is only now adding String.join(). At least it's finally getting lambdas.
|
# ? Feb 17, 2014 01:24 |
|
In this thread, CoC encounters a never-before-seen mode of communication, condescension.
|
# ? Feb 17, 2014 01:30 |
|
carry on then posted:In this thread, CoC encounters a never-before-seen mode of communication, condescension. Uhh, no, I think that's a pretty common mode of communication. Kinda shameful you haven't heard of it before
|
# ? Feb 17, 2014 01:34 |
|
Suspicious Dish posted:Obviously, #pragma once would be the best solution, though I'd love to hear from a compiler person if there's anything wrong with that. There are some finicky details that get weird, like with symlinks, and it doesn't let you protect against the same header appearing in multiple places, which sometimes happens. Mostly it's that compiler people see it as an optimization that is no longer necessary. Suspicious Dish posted:I also am very curious why it's a source of undefined behavior according to the spec, however. Is it just the only mechanism they have in the spec to say "this code may break when it clashes with the system headers"? Yes. It's not diagnosable, so you can't rely on the code actually failing to compile, so you have to assume that the program might just be arbitrarily and subtly hosed up when you try to run it, i.e. it has undefined behavior.
|
# ? Feb 17, 2014 01:40 |
|
I guess I'm happier with the syntax of #pragma once rather than having to append UUIDs to header guards. So, sure, it's an "optimization" in that you don't have to reparse headers, but I think it makes the code a lot cleaner and should be recommended or supported more. And thanks for explaining why it's undefined behavior. That makes perfect sense, I guess I'm just too used to thinking of "undefined behavior" means "your computer blows up", not "it will break in certain cases, but if you're careful and know what you're doing it will work out perfectly OK".
|
# ? Feb 17, 2014 01:49 |
|
I generally favor header guards for public headers, #pragma once for internal headers that make sense to include in other headers, and nothing in internal headers that shouldn't be included from other headers. With #pragma once a file's path is the file's unique identifier, while with header guards the unique identifier has to be manually assigned. Manual assignment is obviously an extra minor hassle and room to gently caress things up, but if some application wants to install copies of my library's headers in three places and include all three of them, I should support that, since there are occasionally legitimate reasons for it. OTOH, there's no reason to support having multiple copies of my application's internal headers floating around, and I'd actually prefer a compilation error if that happened by accident. There's no performance difference (Chromium actually found #pragma once was trivially slower than header guards), so that doesn't factor in to the decision.
|
# ? Feb 17, 2014 07:09 |
|
Suspicious Dish posted:I guess I'm happier with the syntax of #pragma once rather than having to append UUIDs to header guards. So, sure, it's an "optimization" in that you don't have to reparse headers, but I think it makes the code a lot cleaner and should be recommended or supported more. Sure. I don't really accept what I've described as the "compiler people" stance, despite being one, because I think there are user-model justifications for the feature even if there are no longer implementation justifications. I'm just saying that the feature was first introduced and championed for reasons that are now seen as outdated because everybody understands how to do the standard optimization, and that leads people to dismiss it without looking for other benefits, and that's why it's making very little committee headway. Suspicious Dish posted:And thanks for explaining why it's undefined behavior. That makes perfect sense, I guess I'm just too used to thinking of "undefined behavior" means "your computer blows up", not "it will break in certain cases, but if you're careful and know what you're doing it will work out perfectly OK". IIRC, there's some bit of undefined behavior (or there used to be?) around not ending a source file in a newline, basically because there were compilers that sometimes dropped such lines, and there was pressure not to declare them non-compliant. It's kindof a different category of undefined behavior in some ways. On the other hand, pre-LTO, the "types of declarations should be compatible between translation units" UB rule was in that same category, if you consider it defined by being hard to imagine an implementation that would screw things up because of it.
|
# ? Feb 17, 2014 07:31 |
|
I use #pragma once, not as any kind of optimisation but just because it's far less ugly. I've also had several times where someone copy-pasted a header and forgot to change a guard, it worked fine for several years, then broke when stuff got included in the wrong combination. It can be an absolute bastard to track down.
|
# ? Feb 17, 2014 14:03 |
|
Plorkyeran posted:I generally favor header guards for public headers, #pragma once for internal headers that make sense to include in other headers, and nothing in internal headers that shouldn't be included from other headers. pragma once is also not part of any standard so presumably the bot would open a ticket against using undefined behavior in the code. Also Chromium's findings were compiler specific if I remember correctly. Some were faster one was slower.
|
# ? Feb 17, 2014 15:02 |
|
Hughlander posted:pragma once is also not part of any standard so presumably the bot would open a ticket against using undefined behavior in the code. Hughlander posted:Also Chromium's findings were compiler specific if I remember correctly. Some were faster one was slower.
|
# ? Feb 17, 2014 15:58 |
|
Plorkyeran posted:#pragma is implementation-defined, not undefined. Sorry, yes I meant non-standard not undefined. I was mostly bringing it back to the fact we were talking about a bot trolling an issue tracker.
|
# ? Feb 17, 2014 16:23 |
|
qntm posted:Here's a coding horror: it is 2014 and Java is only now adding String.join(). Wake me up when they have an official Base 64 API
|
# ? Feb 17, 2014 17:17 |
|
qntm posted:Here's a coding horror: it is 2014 and Java is only now adding String.join(). Also loving C++ got lambdas before them.
|
# ? Feb 17, 2014 18:46 |
|
Ithaqua posted:At least it's finally getting lambdas. Countdown to corporate style guides prohibiting them and any form of type inference....
|
# ? Feb 17, 2014 19:05 |
|
They will by virtue of still not being updated from Java 1.4.
|
# ? Feb 17, 2014 22:28 |
|
Ithaqua posted:No, the tool is perfect. It's your fault for not knowing how it represents your data internally and for not mapping out your commit history on graph paper so that you can figure out the correct commands to invoke. There are a bunch of tools that will do this for you.
|
# ? Feb 17, 2014 23:12 |
|
Tuning the performance of a 400-line method with things like "if (true) {" and "// I'm sure there are better ways, but I don't know them and I'm in a hurry" and a database hit for every single row in a thousands-of-rows-long CSV is terrible.
|
# ? Feb 17, 2014 23:15 |
|
So I've just seen my first API horror. The part that gets me is this: code:
Context: Old code at work basically makes a delegate to a function that only ever returns false. It's passed into the method and never used. Why not just make an overload that doesn't need this? Why an integer pointer that's just always zero? If the delegate is to a function that only ever returns false and the pointer must be zero why bother adding them at all!?!
|
# ? Feb 18, 2014 00:20 |
|
2banks1swap.avi posted:Old code at work basically makes a delegate to a function that only ever returns false. It's passed into the method and never used. It screams passive aggressive "the architect made it this way and I have no power to change it". Alternatively, laziness.
|
# ? Feb 18, 2014 00:46 |
|
|
# ? Jun 6, 2024 10:00 |
|
This is the loving .NET standard library. WTF, Microsoft?
|
# ? Feb 18, 2014 01:07 |