Foot shooting

Zecc

Step 1: start "sketching" code for a nice utility method that factors away a bunch of logic you find yourself repeating again and again.

Step 2: while changing your heart on how the method should be structured, (correctly) assess that's it's probably a good idea to create a quick copy of the source file in case you regret your future edits, but not worth it stashing it into your version control at this point. Don't bother renaming it from 'ExperimentalMethodExtensions - Copy.cs' or moving it to another directory, since it's really just a quick safety net. Obviously, don't add this copy to the project.

Step 2: be happy with your changes, having sufficiently tested them. Rename class to WellTestedMethodExtensions and commit the original file, now renamed to WellTestedMethodExtensions.cs, to source control.

Step 3: start relying on your nice extension method a bit throughout your codebase. Completely forget about the temporary file, since it's not included in the .csproj file nor has it been added to your version control system, so it "doesn't exist". Learn to, as time passes, ignore it when you see it listed as an unknown file in your source control status. Don't bother deleting because meh, it's not hurting anyone.

Step 4: decide the writing's on the wall and it's time to start looking into .Net Core, or at least convert the project to .Net Standard since it's just a bunch of business logic without any platform-specific stuff in it.

Step 4.1: be oblivious to the fact that among other changes, the new .csproj format doesn't list any source files, but instead by default considers all .cs files in the directory to be part of the codebase (which is sensible).

Step 4.2: very important step Ensure than during step 2 you have renamed the class, so that the compiler doesn't complain about a non-partial class being declared in two separate files. You need to have two classes implementing the "same"extension method.

Step 4.2.5: also very important Ensure that you've inadvertently made the extension method in the '- copy.cs' file a proper overload of the method you're using elsewhere. Also that it's actually picked by the compiler in some call sites, so that it's not just an unused method, but also that it's not exactly the same so the compiler doesn't complain about an ambiguous call.
This means you mustn't have changed its name since you've made the copy, that the return type should have remained valid and compatible, and that the arguments should be different yet similar: perhaps it previously took an argument with a narrower type rather than a common base class; perhaps it now takes an optional argument that is frequently specified but not always. Bonus points if you do both.

If you've followed all steps carefully, congratulations! You now have introduced buggy code to builds compiled in your machine, while being completely invisible to code reviews done elsewhere.

Zecc

Step 7.264: when you proofread your post, also make sure you haven't repeated step 2.

Captain

That's pretty bad. :-)

I just had a (more basic, but similar in spirit) drive by foot shooting here. I had a piece of logic that was like:

if (obj.getINVS_CLT_CD_PRVD_ORG is null) {
   setTextField("providerOrg", "");
} else {
  setTextField("providerOrg", obj.getINVS_CLT_CD_PRVD_ORG );
}

(I'll explain a little -- we use Struts' ORM or whatever to populate our "forms", so there's a name-based convention to put the DB data into the matching form field. This happens virtually silently about 5000 lines above the preceding code).

SO, this was always coming in as empty. Hm. But if I run a query to join CLT and INVS, the CLT row has a ID_PRVD_ORG. HMM.

SO WHERE IS THIS GETTING BROKEN IN THE LAST 5000 LINES OF CODE.

Oh, it's in the query, which doesn't select the CLT.ID_PRVD_ORG so it doesn't get put into the hashmap that represents a database row. So it comes up as null when in the code I posted.

Mason_Wheeler

@Zecc said in Foot shooting:

Step 3: start relying on your nice extension method a bit throughout your codebase. Completely forget about the temporary file, since it's not included in the .csproj file nor has it been added to your version control system, so it "doesn't exist". Learn to, as time passes, ignore it when you see it listed as an unknown file in your source control status. Don't bother deleting because meh, it's not hurting anyone.

I read this and immediately thought, "this is gonna turn into a mess when you upgrade to the new csproj format..."

JBert

... and this is why I run git clean (-something -something) every other week or so.

Magus

@levicki yeah no.

JBert

@levicki said in Foot shooting:

Why would you want an IDE to assume your intent?

What's wrong with specifying files that are part of the project and thus get compiled?

Convention over configuration is a thing. Build tools like Maven have been doing it for years: everything in src/main/java gets built, no exceptions. The downside of having to explicitly include files might mean that sometimes code is not included when it should have been, while convention-based setups mean that whatever is visible in your file explorer is what gets built in the IDE / build tool.
It's a PITA when you're frequently merging branches which all add new files - at least for project files like Visual Studio's where XML tags can get misaligned by naïve merge tools.

HardwareGeek

@JBert said in Foot shooting:

XML

dkf

@levicki said in Foot shooting:

What's to stop a malicious actor from dropping a file in your project folder

As opposed to all the myriad other ways a malicious actor with write access to your machine can cause mischief?

HardwareGeek

@dkf Something about an airtight hatch?

Steve_The_Cynic

@JBert said in Foot shooting:

@levicki said in Foot shooting:

Why would you want an IDE to assume your intent?

What's wrong with specifying files that are part of the project and thus get compiled?

Convention over configuration is a thing. Build tools like Maven have been doing it for years: everything in src/main/java gets built, no exceptions. The downside of having to explicitly include files might mean that sometimes code is not included when it should have been, while convention-based setups mean that whatever is visible in your file explorer is what gets built in the IDE / build tool.

It might be a thing, but it smells very strongly of the machine deciding what to do rather than being told what to do. The problem with any instance of that is that the machine's criteria for deciding to do or not do something are almost always capable of completely shredding POLA.

Or maybe I'm just old-fashioned. Or just old. Not sure.

It's a PITA when you're frequently merging branches which all add new files - at least for project files like Visual Studio's where XML tags can get misaligned by naïve merge tools.

If the alignment of XML tags matters, you go round to where the people who made the parser live and chastise them with your GAU-8. Geez.

Steve_The_Cynic

@Zecc said in Foot shooting:

Step 1: start "sketching" code for a nice utility method that factors away a bunch of logic you find yourself repeating again and again.

So far, so good.

Step 2: while changing your heart on how the method should be structured, (correctly) assess that's it's probably a good idea to create a quick copy of the source file in case you regret your future edits, but not worth it stashing it into your version control at this point. Don't bother renaming it from 'ExperimentalMethodExtensions - Copy.cs' or moving it to another directory, since it's really just a quick safety net. Obviously, don't add this copy to the project.

You are TR, especially with version control like git, where your local experimentation can remain local.

Step 2: be happy with your changes, having sufficiently tested them. Rename class to WellTestedMethodExtensions and commit the original file, now renamed to WellTestedMethodExtensions.cs, to source control.

Less of a , but still in the running.

Step 3: start relying on your nice extension method a bit throughout your codebase. Completely forget about the temporary file, since it's not included in the .csproj file nor has it been added to your version control system, so it "doesn't exist". Learn to, as time passes, ignore it when you see it listed as an unknown file in your source control status. Don't bother deleting because meh, it's not hurting anyone.

Obviously that's not true, given what follows.

Step 4: decide the writing's on the wall and it's time to start looking into .Net Core, or at least convert the project to .Net Standard since it's just a bunch of business logic without any platform-specific stuff in it.

Step 4.1: be oblivious to the fact that among other changes, the new .csproj format doesn't list any source files, but instead by default considers all .cs files in the directory to be part of the codebase (which is sensible).

As noted, it's not sensible. The files to compile are the ones you want compiled, not the ones that happen to be lying around.

Tsaukpaetra

@Steve_The_Cynic said in Foot shooting:

not the ones that happen to be lying around.

See Also: PHP

masterX244179

@Steve_The_Cynic said in Foot shooting:

@JBert said in Foot shooting:

@levicki said in Foot shooting:

Why would you want an IDE to assume your intent?

What's wrong with specifying files that are part of the project and thus get compiled?

Convention over configuration is a thing. Build tools like Maven have been doing it for years: everything in src/main/java gets built, no exceptions. The downside of having to explicitly include files might mean that sometimes code is not included when it should have been, while convention-based setups mean that whatever is visible in your file explorer is what gets built in the IDE / build tool.

It might be a thing, but it smells very strongly of the machine deciding what to do rather than being told what to do. The problem with any instance of that is that the machine's criteria for deciding to do or not do something are almost always capable of completely shredding POLA.

Or maybe I'm just old-fashioned. Or just old. Not sure.

It's a PITA when you're frequently merging branches which all add new files - at least for project files like Visual Studio's where XML tags can get misaligned by naïve merge tools.

If the alignment of XML tags matters, you go round to where the people who made the parser live and chastise them with your GAU-8. Geez.

Mergetools might sometimes whack off a closing tag or mix up the balancing so the XML is syntactically broken. Also have fun when you get a mergeconflictmarker inside the csproj file. YOu need to go to the file with a different editor to fix that.

ben_lubar

@levicki said in Foot shooting:

What's to stop a malicious actor from dropping a file in your project folder

not a fan of the filesystem you're using that has permissions for files but not folders

remi

@levicki said in Foot shooting:

@Zecc said in Foot shooting:

the new .csproj format doesn't list any source files, but instead by default considers all .cs files in the directory to be part of the codebase (which is sensible).

That's absolutely not sensible. That's HORRIBLE.

Why would you want an IDE to assume your intent?

What's wrong with specifying files that are part of the project and thus get compiled?

I can't count how many times n00b stupid cow-orkers (but I repeat myself) have whined to me that they've added a file but it's not compiled, because they forgot to add it in the list of files. Or maybe they thought about adding the header file but not the source (or the other way round). Or they added it to the wrong part of the configuration file (e.g. hard-coding the name of the file in some place rather than properly adding it to the variable that contains the list of all files -- depending on the build system used). Or various other ways in which "specifying files" isn't that easy.

I mean, I kind of agree with you that it has some drawbacks, but experience shows that the other way also had very clear drawbacks. Of course, you're going to retort that they are crap developers that shouldn't be let near a computer and your usual elitist shtick.

With this new way you can't temporarily remove code unless you move a file out of the project folder which almost guarantees that you will lose it or delete it by accident.

Yeah, if you only you could just... rename the file? (I usually change it to foo.h.old or something similar)

dkf

@Steve_The_Cynic said in Foot shooting:

It might be a thing, but it smells very strongly of the machine deciding what to do rather than being told what to do.

It's not a problem here as long as everyone is expecting “compile everything in this source tree” to be the instruction given. The issue is (partially) that the expectation has changed.

dkf

@remi said in Foot shooting:

Or various other ways in which "specifying files" isn't that easy.

The only sane way to fix that is to have a strict rule that builds only count if they're not made on a developer's machine. Like that, if they want it to count they have to commit it (and not bind everything to the exact locations on their own system).

Yes, people will forget from time to time. That's when they should have the rest of the team laugh at them as cruelly as possible.

Steve_The_Cynic

@masterX244179 said in Foot shooting:

@Steve_The_Cynic said in Foot shooting:

@JBert said in Foot shooting:

@levicki said in Foot shooting:

Why would you want an IDE to assume your intent?

What's wrong with specifying files that are part of the project and thus get compiled?

Convention over configuration is a thing. Build tools like Maven have been doing it for years: everything in src/main/java gets built, no exceptions. The downside of having to explicitly include files might mean that sometimes code is not included when it should have been, while convention-based setups mean that whatever is visible in your file explorer is what gets built in the IDE / build tool.

It might be a thing, but it smells very strongly of the machine deciding what to do rather than being told what to do. The problem with any instance of that is that the machine's criteria for deciding to do or not do something are almost always capable of completely shredding POLA.

Or maybe I'm just old-fashioned. Or just old. Not sure.

It's a PITA when you're frequently merging branches which all add new files - at least for project files like Visual Studio's where XML tags can get misaligned by naïve merge tools.

If the alignment of XML tags matters, you go round to where the people who made the parser live and chastise them with your GAU-8. Geez.

Mergetools might sometimes whack off a closing tag or mix up the balancing so the XML is syntactically broken. Also have fun when you get a mergeconflictmarker inside the csproj file. YOu need to go to the file with a different editor to fix that.

Sure, but that's not the alignment of the tags. Or, rather, by "alignment" I read "the spaces around them", which any proper XML parser should just plain ignore, subject to some oddities about the difference between:

<sometag>Some text</sometag>

and

<sometag>
Some text
</sometag>

or the difference between

<sometag />

and

<sometag></sometag>

MrL

@JBert said in Foot shooting:

Convention over configuration is a thing.

Yeah, a bad thing.

JBert

@Steve_The_Cynic In this case I wasn't talking about the literal alignment of tags using whitespace. It's XML we're talking about here so it was meant to go about handling closing tags.

For example, here is how different XMLs get shown in a 3-way merge tool and how they fail to properly merge if you do a simple "first B, then C":

The </Content> end tag is common in both versions so it doesn't get seen as something which needs merging. The simple "first B, then C" strategy thus means that you're missing that end tag in between B and C and need to go editing. Repeat multiple times if you've got a big XML file. (Different tools might do things differently, I'm too lazy to go and see how it would look in Visual Studio's compare tools).

As for those saying "don't use XML then": having a project file with explicit includes but no XML might still mean pain when your "list of files" need to be merged.

Suppose you have a list of files and the list uses delimiters like , except for the last item in the list (i.e. no dangling delimiters). Merging then means that when two branches both add files to the end of the list then you will need to modify one of the two entries so that the list delimiters are correct.

HardwareGeek

@Tsaukpaetra said in Foot shooting:

@Steve_The_Cynic said in Foot shooting:

not the ones that happen to be lying around.

See Also: PHP

No.

:the_goggles_do_nothing.xlsx:

HardwareGeek

@remi said in Foot shooting:

that they are crap developers that shouldn't be let near a computer

Part of Sturgeon's 90%. Indubitably.

dcon

@JBert said in Foot shooting:

... and this is why I run git clean (-something -something) every other week or so.

Oh, I thought that was some new super cool git command (why not???)

>git clean ( -something -something )
error: unknown switch `s'
usage:

Steve_The_Cynic

@JBert said in Foot shooting:

The </Content> end tag is common in both versions so it doesn't get seen as something which needs merging. The simple "first B, then C" strategy thus means that you're missing that end tag in between B and C and need to go editing. Repeat multiple times if you've got a big XML file. (Different tools might do things differently, I'm too lazy to go and see how it would look in Visual Studio's compare tools).

Yeah, I know that problem. Something related to it can happen with e.g. C or C++ code, where a blind B-then-C ends up with one copy each of:

An if() and its opening brace
A different if() and its opening brace
The closing brace

As for those saying "don't use XML then":

Er, they should say the same thing about almost any other language or document format with an essentially-mandatory closing element (slash-tag in the SGML family, brace in the braced languages, end in Pascalitorious languages, etc.).

dkf

@JBert said in Foot shooting:

As for those saying "don't use XML then": having a project file with explicit includes but no XML might still mean pain when your "list of files" need to be merged.

You can get similar categories of problems with both JSON and YAML.

anonymous234

@JBert said in Foot shooting:

Convention over configuration is a thing. Build tools like Maven have been doing it for years: everything in src/main/java gets built, no exceptions. The downside of having to explicitly include files might mean that sometimes code is not included when it should have been, while convention-based setups mean that whatever is visible in your file explorer is what gets built in the IDE / build tool.

Convention over configuration is a shitty pattern. Or at least the Microsoft implementations are shitty.

I want to be able to look at things from the bottom up, and know what the fuck they're actually doing. I hate this "put the files here and it works, don't ask questions, just trust us" mentality.
Automatically compiling all .cs files is a good idea in general. But why can't Microsoft autogenerate or include a SHORT, and READABLE script that does that?

From the documentation:

While those csproj changes greatly simplify project files, you might want to see the fully expanded project as MSBuild sees it once the SDK and its targets are included. Preprocess the project with the /pp switch of the dotnet msbuild command, which shows which files are imported, their sources, and their contributions to the build without actually building the project

Sounds great right? EXCEPT THE OUTPUT FILE HAS >14,000 LINES. That's where you're expected to find out "which files are imported, their sources, and their contributions to the build".

dkf

@anonymous234 said in Foot shooting:

EXCEPT THE OUTPUT FILE HAS >14,000 LINES.

You're making me feel good about Maven. Stop it.

marczellm

@anonymous234 said in Foot shooting:

at least the Microsoft implementations are shitty.

Case in point. Creating a blank ".NET Core server + Angular.js client" project in VS, you get out of the box support for debugging your TypeScript code after it was compiled to minified JS and is running in the browser.

But if that doesn't work, good luck finding where that "out of the box" support is and how many ways it could fail.

remi

@levicki said in Foot shooting:

Let's say you are a standalone developer and you are producing some highly successful app. Someone can compromise your PC in a myriad of ways, but they shouldn't be able to produce a signed executable of your app and publish it instead of you because there is a password to the private key which you must enter when building a release.

However, if they can drop a .cs file into your project folder, their code will get built into your app, and you will publish it without noticing because the file is not listed in the solution tree.

@error_bot xkcd cryptonerd dream

How low are we going to bend over backwards to please stupid people?

Called it

your usual elitist shtick.

error_bot

xkcd said in https://xkcd.com/214/ :

The Problem with Wikipedia

'Taft in a wet t-shirt contest' is the key image here.

)

remi

Look @error_bot, this is how it's done:

https://www.google.com/search?q=xkcd cryptonerd dream

First hit:

Zecc

@levicki said in Foot shooting:

When you find a filesystem which can prevent writing to a folder when you boot the PC from a different OS please let us know.

When you find a compiler which can successfully detect a new file was added to the project without your knowledge while the OS was down (regardless of the intricacies of how it is elected for compilation) let us know.

remi

@levicki said in Foot shooting:

Problem is that there is less and less of normal people, and being an idiot is becoming a norm.

I feel like I'm stuck in an infinite loop...

your usual elitist shtick.

remi

@levicki Sometimes, no, and sometimes.

ben_lubar

@levicki said in Foot shooting:

When you find a filesystem which can prevent writing to a folder when you boot the PC from a different OS please let us know. Unless you are saying that everyone is using pre-boot authentication and full disk encryption?

A hostile actor has physical access to your computer and you're worried about the build system?

remi

@ben_lubar Wow. Ben and I answered basically in the same way, but I just posted a picture (OK, tried (and failed, as usual) to get error_bot to do it for me) while Ben actually used words explaining things.

I must have crossed over to Earth-73 or something.

remi

@levicki said in Foot shooting:

I wish I could get frozen for a 1,000 years, perhaps this collective stupidity, backwardness, and lack of common sense will be cured until then.

If you actually, sincerely, believe that this is anything but standard and eternal human nature, then you are much more stupid than I thought.

mott555

We have projects that include files by source name because there are different configurations that use slightly different lists of source files to compile, mostly to support other operating systems or slightly different customer scenarios. If that changed to just wildcard include all source files, it would break horribly.

remi

@levicki said in Foot shooting:

I remember the world 30 years ago -- it wasn't this bad

Chose your own adventure!

[A] you're viewing the past through rose-tinted glasses
[B] 30 years ago you were the n00b

(inb4: why not both?)

boomzilla

@levicki said in Foot shooting:

However, if they can drop a ~~.cs file~~roofie into your ~~project folderwhiskey~~coffee...

How the fuck are they dropping a file in so nonchalantly that it's not a minor symptom of much more serious problems?

boomzilla

@levicki said in Foot shooting:

Normal people don't complain how everything is too hard

That's what she said.

Zecc

@levicki said in Foot shooting:

A hostile actor might have physical access to your computer but still not be able to do much without master password for your Keepass database, and without your Yubikey token (and without raising suspicion).

Phew. I was afraid they'd surreptitiously add a source file to one of my projects or something.

Mason_Wheeler

@boomzilla said in Foot shooting:

@levicki said in Foot shooting:

Normal people don't complain how everything is too hard

That's what she said.

For whatever reason, I read that and immediately imagine something being said by some Chinese person named Shi, similar to the you/Yu scene from Rush Hour.

hungrier

@Steve_The_Cynic said in Foot shooting:

Yeah, I know that problem. Something related to it can happen with e.g. C or C++ code, where a blind B-then-C ends up with one copy each of:

An if() and its opening brace
A different if() and its opening brace
The closing brace

I've had something sort of like that in a C# project, although I don't recall if it happened because of a merge or just someone being careless and leaving the (hard to spot) error.

if (someCondition) 
{
    // ...
}
else if (someOtherCondition)
{
    // ...
}
else
{
    // ...
}

Somehow turned into

if (someCondition) 
{
    // ...
}
if (someOtherCondition)
{
    // ...
}
else
{
    // ...
}

So instead of exactly one of three things happening, sometimes two of them would happen in sequence, which caused a subtle problem that only visibly manifested later on in the process.

anonymous234

@levicki said in Foot shooting:

When you find a filesystem which can prevent writing to a folder when you boot the PC from a different OS please let us know. Unless you are saying that everyone is using pre-boot authentication and full disk encryption?

Microsoft is very insistent on using Secure Boot™ and transparent full-disk encryption on all systems nowadays, so I think Windows fully qualifies as that.

Anyway, having to keep a list of files to compile is obviously bad because it's redundant information. Don't repeat yourself and all that.

hungrier

@remi said in Foot shooting:

@error_bot xkcd cryptonerd dream

@remi said in Foot shooting:

Look @error_bot, this is how it's done:

xkcd - Google Search

cryptonerd dream

Actually, what you want is
@error_bot xkcd personal villains

error_bot

xkcd said in https://xkcd.com/538/ :

Security

Actual actual reality: nobody cares about his secrets. (Also, I would be hard-pressed to find that wrench for $5.)

(via https://www.explainxkcd.com/wiki/index.php?search=personal+villains&title=Special%3ASearch&fulltext=1)

HardwareGeek

@levicki said in Foot shooting:

If that's the reason to say I am stupid so be it. At least I am an optimist.

I wouldn't call optimism stupid, just delusional.

boomzilla

@Mason_Wheeler said in Foot shooting:

@boomzilla said in Foot shooting:

@levicki said in Foot shooting:

Normal people don't complain how everything is too hard

That's what she said.

For whatever reason, I read that and immediately imagine something being said by some Chinese person named Shi, similar to the you/Yu scene from Rush Hour.

And then you shared that thought with us.