Coding Horrors: You can gather all your technical debt into one easy framework!

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Coding Horrors: You can gather all your technical debt into one easy framework!

«‹›1503 »

Steve French: Sep 8, 2003

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.

Of course the cherry-picked commit will have its own new auto-generated change-ID, so when squashing I have to remember to copy-paste the original one to the bottom of the commit message or else Gerrit will still see the whole squashed thing as a brand new changeset and start a fresh review.

Save yourself the headache and amend the commit that you need to change.

# ? Feb 14, 2014 16:06

Adbot: ADBOT LOVES YOU

# ? Jun 5, 2024 19:06

Suspicious Dish: Sep 24, 2011; 2020 is the year of linux on the desktop, bro; Fun Shoe

Was trying to book a flight today:

JavaScript code:

function TestNameValue(namevalue) {
    var status = true;
    var atest = /^[A-Za-z\s\-]+$/;

    if (namevalue.length == 0 || (/^\s*$/).test(namevalue))
        return status;

    // test for special characters
    var ss = namevalue.replace(/^\s*/, "").replace(/\s*$/, "");
    if (!ss.match(atest)) {
        status = false;
    }
    // check for multiple words
    //if (ss.split(" ").length - 1 > 1) {
    //    status = false;
    //}
    return status;
}

function ValidateContactName()
{
    var status = true;
    var ds = document.SkySales;
    var tbFirstName = ds['ControlGroupContactView$ContactInputContactView$TextBoxFirstName'];
    var tbLastName = ds['ControlGroupContactView$ContactInputContactView$TextBoxLastName'];

    if (tbFirstName != null && tbLastName != null) {
        if (!TestNameValue(tbFirstName.value) || !TestNameValue(tbLastName.value)) {
            status = false;
            alert("Contact name is invalid.");
        }
    }
    return status;
}

My legal name is "Jasper St. Pierre"

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

Carthag Tuek: Oct 15, 2005; Tider skal komme,
tider skal henrulle,
sl�gt skal f�lge sl�gters gang

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

hackbunny: Jul 22, 2007; I haven't been on SA for years but the person who gave me my previous av as a joke felt guilty for doing so and decided to get me a non-shitty av

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:

low pay compared to countries like the USA
short-term contracts or worse (per-project contracts, endless internships, etc.). Some places don't pay at all, nor even offer you a share of the company
forced to register as consultants to be hired. This is expensive, shifts the burden of accounting on the employee and in no way guarantees a consultant's pay
unwritten, unofficial understanding that you'll do tech support/system administration if necessary

I'm lucky in that the only issue I have with my employer is a low pay (again, compared to other countries)

hackbunny fucked around with this message at 17:34 on Feb 14, 2014

# ? Feb 14, 2014 17:32

Sulla Faex: May 14, 2010; No man ever did me so much good, or enemy so much harm, but I repaid him with ENDLESS SHITPOSTING

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:

low pay compared to countries like the USA (Check)

short-term contracts or worse (per-project contracts, endless internships, etc.) (Check). Some places don't pay at all, nor even offer you a share of the company

forced to register as consultants to be hired. This is expensive, shifts the burden of accounting on the employee and in no way guarantees a consultant's pay

unwritten, unofficial understanding that you'll do tech support/system administration if necessary (Check)

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

Dirty Frank: Jul 8, 2004

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

qntm: Jun 17, 2009

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.

http://www.kalzumeus.com/2010/06/17/falsehoods-programmers-believe-about-names/

My middle initial is U+0000

# ? Feb 15, 2014 22:49

Uziel: Jun 28, 2004; Ask me about losing 200lbs, and becoming the Viking God of W&W.

qntm posted:

My middle initial is U+0000

Null is a really common last name!

# ? Feb 15, 2014 22:51

That Turkey Story: Mar 30, 2003

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

Gazpacho: Jun 18, 2004; by Fluffdaddy; Slippery Tilde

That Turkey Story posted:

It's not petty and these are valid criticisms/bugs. Sorry you like encouraging poor code.

It's petty until someone in that thread comes up with a failure scenario, preferably one that doesn't start with "how do you think about to". (Don't post it here.)

# ? Feb 16, 2014 09:35

het: Nov 14, 2002; A dark black past
is my most valued
possession

That Turkey Story posted:

It's not petty and these are valid criticisms/bugs. Sorry you like encouraging poor code.

I think it's less petty than people make it out to be, but beyond leading underscores, the more important thing is to encourage some unique-to-your-project header guard rather than one that might conflict with other dependent libraries.

# ? Feb 16, 2014 10:21

Smugdog Millionaire: Sep 14, 2002; 8) Blame Icefrog

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

Suspicious Dish: Sep 24, 2011; 2020 is the year of linux on the desktop, bro; Fun Shoe

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

zergstain: Dec 15, 2005

Isn't leading underscores reserved for the standard library, of which glibc is an implementation of?

# ? Feb 16, 2014 16:31

Pollyanna: Mar 5, 2005; Milk's on them.

I've never seen broken English that is also extremely condescending before. First time for everything, I suppose.

# ? Feb 16, 2014 21:59

Gazpacho: Jun 18, 2004; by Fluffdaddy; Slippery Tilde

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

SurgicalOntologist: Jun 17, 2004

It's a bot, people.

# ? Feb 16, 2014 22:54

qntm: Jun 17, 2009

Here's a coding horror: it is 2014 and Java is only now adding String.join().

# ? Feb 17, 2014 00:18

rjmccall: Sep 7, 2007; no worries friend; Fun Shoe

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

Suspicious Dish: Sep 24, 2011; 2020 is the year of linux on the desktop, bro; Fun Shoe

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

New Yorp New Yorp: Jul 18, 2003; Only in Kenya.; Pillbug

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

carry on then: Jul 10, 2010; by VideoGames
(and can't post for 10 years!)

In this thread, CoC encounters a never-before-seen mode of communication, condescension.

# ? Feb 17, 2014 01:30

coffeetable: Feb 5, 2006; TELL ME AGAIN HOW GREAT BRITAIN WOULD BE IF IT WAS RULED BY THE MERCILESS JACKBOOT OF PRINCE CHARLES

YES I DO TALK TO PLANTS ACTUALLY

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 :smug:

# ? Feb 17, 2014 01:34

rjmccall: Sep 7, 2007; no worries friend; Fun Shoe

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

Suspicious Dish: Sep 24, 2011; 2020 is the year of linux on the desktop, bro; Fun Shoe

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

Plorkyeran: Mar 22, 2007; To Escape The Shackles Of The Old Forums, We Must Reject The Tribal Negativity He Endorsed

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

rjmccall: Sep 7, 2007; no worries friend; Fun Shoe

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

Rottbott: Jul 27, 2006; DMC

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

Hughlander: May 11, 2005

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.

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.

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

Plorkyeran: Mar 22, 2007; To Escape The Shackles Of The Old Forums, We Must Reject The Tribal Negativity He Endorsed

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.

#pragma is implementation-defined, not undefined.

Hughlander posted:

Also Chromium's findings were compiler specific if I remember correctly. Some were faster one was slower.

Well yes, but the point is that the difference in all cases was basically a rounding error.

# ? Feb 17, 2014 15:58

Hughlander: May 11, 2005

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

hackbunny: Jul 22, 2007; I haven't been on SA for years but the person who gave me my previous av as a joke felt guilty for doing so and decided to get me a non-shitty av

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

Look Around You: Jan 19, 2009

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

1337JiveTurkey: Feb 17, 2005

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

carry on then: Jul 10, 2010; by VideoGames
(and can't post for 10 years!)

They will by virtue of still not being updated from Java 1.4.

# ? Feb 17, 2014 22:28

RICHUNCLEPENNYBAGS: Dec 21, 2010

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

it is: Aug 19, 2011; by Smythe

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

Fuck them: Jan 21, 2011; and their bullshit

So I've just seen my first API horror.

The part that gets me is this:

code:

Note   You must create a delegate and pass a reference to the delegate as the callback parameter, but the delegate is not used.

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!?! :psyduck:

# ? Feb 18, 2014 00:20

baquerd: Jul 2, 2007; by FactsAreUseless

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.

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!?!

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

Adbot: ADBOT LOVES YOU

# ? Jun 5, 2024 19:06

Fuck them: Jan 21, 2011; and their bullshit

This is the loving .NET standard library.

WTF, Microsoft?

# ? Feb 18, 2014 01:07

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Coding Horrors: You can gather all your technical debt into one easy framework!

«‹›1503 »