Arg... I hate bad coders!

[DWW]

I was given some specs and told what to anticipate from those calling functions in the lib I was writing. Turns out they are not so compotent and passed excessive data -knowingly-.

I should have taken more time and used what I know about secure coding (eg NEVAR use strcpy) because I've been trying to focus on that quite a lot lately (reading both the recent Oreilly texts) but it was a situation where the destination is ALWAYS suppose to be ample size. I thought my peer had half a brain. Sure I could use strncpy and I do now, but, for the sake of the thing (it was small) and he knew what was required of him and the bounds checking on his side.

I guess, you should -always- assume people are stupid. I don't know. I am the type of guy who thinks private members in classes aren't really necessary because the documentation should just outline areas not for the end coder and that it should be understood. If you really have to hide stuff and make it inaccessible purposely, what does that say about the anticipated user of it? Then again I'm not big into OOP.

Now I just spent a good half hour and found the source of a core dump. Hrm if I had nothing against thinkgeek I'd almost want this shirt.

 

[DurocShark]

Always assume that the end user will do exactly what you tell him/her NOT to do.

Hence, good error trapping and restricted fields.

 

[ggavinmoss]

Sucks.

By the way, what do you have against thinkgeek?

-geoff

 

[Lonyo]

I got a similar thing to that in Walmart, so you don't need to go to Thinkgeek. Had smaller writing, in 80's computer game style, and was long sleeved. Much better than the one there.

 

[DWW]

ggavinmoss: I think a lot of their stuff is too corny and cliche. They kind of overplay the nerd stuff. I don't know... some shirts like the type that say "hacker" on the front of them cry for attention (IMO) so they cater to a group I don't really want to be part of.

But that is just my opinion so don't get angry if your a frequent shopper

 

[CChaos]

Originally posted by: DWW
If you really have to hide stuff and make it inaccessible purposely, what does that say about the anticipated user of it?[/L]

To me, it says that they will use it properly. It sounds to me like the issue isn't bad code, but bad design or communication.

They have been pushing us here at work to have all documentation complete before we even begin coding. This is partly because of the lack of control in the past but also part of an effort to quantify everything we do here. This is probably a non-issue for most people, but I'm still relatively new so it's hard for me to forsee all the implications of a project without getting in and tinkering with things. In a perfect world, I guess I could tell you exactly what I need to do to make certain changes work and by extension, you would know exactly how to interface with me. In reality, things may need to change even in the course of a small project. However, there's no excuse for me not to communicate those changes if it's going to break something. Of course it's my stuff that will break so I really don't have a choice!

EDIT: I forgot to mention that pretty much all I do is make enhancements or changes to an existing and fairly complex system rather than stand alone projects.

 

[ggavinmoss]

Originally posted by: DWW
ggavinmoss: I think a lot of their stuff is too corny and cliche. They kind of overplay the nerd stuff. I don't know... some shirts like the type that say "hacker" on the front of them cry for attention (IMO) so they cater to a group I don't really want to be part of.

But that is just my opinion so don't get angry if your a frequent shopper

No, not a frequent shopper. I think some of the stuff they carry is funny or clever, but a lot of it is just stereotyping.

-geoff

 

[DWW]

ggavinmoss: yeah some stuff is cool but a lot is stereotyping.

 

[Ameesh]

Originally posted by: DWW
I was given some specs and told what to anticipate from those calling functions in the lib I was writing. Turns out they are not so compotent and passed excessive data -knowingly-.

I should have taken more time and used what I know about secure coding (eg NEVAR use strcpy) because I've been trying to focus on that quite a lot lately (reading both the recent Oreilly texts) but it was a situation where the destination is ALWAYS suppose to be ample size. I thought my peer had half a brain. Sure I could use strncpy and I do now, but, for the sake of the thing (it was small) and he knew what was required of him and the bounds checking on his side.

I guess, you should -always- assume people are stupid. I don't know. I am the type of guy who thinks private members in classes aren't really necessary because the documentation should just outline areas not for the end coder and that it should be understood. If you really have to hide stuff and make it inaccessible purposely, what does that say about the anticipated user of it? Then again I'm not big into OOP.

Now I just spent a good half hour and found the source of a core dump. Hrm if I had nothing against thinkgeek I'd almost want this shirt.

hahaha sounds like you are a bit new to this software development thing.. you should always expect that clients of your lib will try and call you with invalid params.

 

[DWW]

Ameesh, naw I've been coding 14 years now. I guess I got too lax and figured my peers were, smarter. I guess you would have had to see the code, requirements etc. It was such a small job that there wasn't need for all the extra overhead on my part. It was mutually left up to him more or less.

 

[Ameesh]

Originally posted by: DWW
Ameesh, naw I've been coding 14 years now. I guess I got too lax and figured my peers were, smarter. I guess you would have had to see the code, requirements etc. It was such a small job that there wasn't need for all the extra overhead on my part. It was mutually left up to him more or less.

14 years, you defintely should be on your toes. i go into writing my code thinking that all my clients are complete morons so i dont get disappointed when i find out they are.



now when i need string functions i always use these whenever possible.

 

[DWW]

It wasn't a client though. It was a coworker that I thought more highly of. The code would NEVER be used outside of us.

 

[FeathersMcGraw]

Originally posted by: DWW

Sure I could use strncpy and I do now, but, for the sake of the thing (it was small) and he knew what was required of him and the bounds checking on his side.

I guess, you should -always- assume people are stupid. I don't know. I am the type of guy who thinks private members in classes aren't really necessary because the documentation should just outline areas not for the end coder and that it should be understood. If you really have to hide stuff and make it inaccessible purposely, what does that say about the anticipated user of it? Then again I'm not big into OOP.

Of course, just using strncpy isn't a panacea, either, since you're now exposing yourself to nonterminated strings.

And not using privacy means you're relying on documentation to do the work of enforcing your standards rather than the compiler. That's a bad practice, and it's not because you should assume your coworkers are stupid, but likely ignorant, particularly as the size of your project scales.

 

[Descartes]

You should positively and absolutely always validate data, *especially* before trying to copy it into a buffer. If you have a contract with the client, you should assert it, literally. Really there is no excuse, and although he may have made a mistake, it's really your job to accommodate all variances. I employ somewhat of a design-by-contract assertion of method preconditions before even thinking about utilizing the data passed in. You'll find that most quality code follows a similar methodology. e.g. in C:

void Foo(const char *p, int x)
{
ASSERT(p != NULL);
ASSERT(x > 0);

// now do something useful
}

A contrived example, but you get the idea. I take it a step further in C#:

void Foo(SomeClass c, int x)
{
if (c == null) throw new ArgumentNullException("DOH");
if (x <= 0) throw new ArgumentOutOfRangeException("DOH");

// something useful
}

I also employ a declarative means of precondition validation using regular expressions for properties that need to conform to specific formats:

[Match("\d{9}")]
protected string phoneNumber;

Then any attempts to set phoneNumber = to anything that isn't 9 digits long gets an exception.

Be on the defensive!

 

[Descartes]

Originally posted by: DWW
It wasn't a client though. It was a coworker that I thought more highly of. The code would NEVER be used outside of us.

You're making some bad assumptions. So far, you've assumed the following:

- All data passed in will be congruous with SPOKEN standards
- The code is so limited in scope (two people) that proper methods need not be employed (validation)

Do it right, everytime. There is no such thing as disposable code, so treat each application as though it's production quality. If you're going to make assumptions, you need to assert them. If you can't assert them, don't assume them; in other words, you can't rightfully assume an application is so limited in scope that it will only be used between two people, so don't code around such an assumption.

I know that there are exceptions, but discipline can go a long way regardless of whether you think it's going to be used outside of your organization.

 

[DWW]

Yeah good advice all. Thanks for it. I'm trying to take coding more serious. I've been doing it 14 years but I'd say 12 of that was hobby and include basic, pascal, turing.

Trying to read into defensive programming and security now. I guess I take an idealogical stance which is bad because it won't happen And I can always dream.

 

[911paramedic]

// Woosh! There goes everything over my head again.

 

[DWW]

911paramedic I like your sig

 

[Ameesh]

Originally posted by: DWW
Yeah good advice all. Thanks for it. I'm trying to take coding more serious. I've been doing it 14 years but I'd say 12 of that was hobby and include basic, pascal, turing.

Trying to read into defensive programming and security now. I guess I take an idealogical stance which is bad because it won't happen And I can always dream.

now it comes out lol, ive been programming for several years seriously and now by default i am suspicious of my user input, almost paranoid. good code will be. regardless if the client is internal or external he is a client and therefore dumb and malicious by default.

 

[Descartes]

Originally posted by: Ameesh

Originally posted by: DWW
Yeah good advice all. Thanks for it. I'm trying to take coding more serious. I've been doing it 14 years but I'd say 12 of that was hobby and include basic, pascal, turing.

Trying to read into defensive programming and security now. I guess I take an idealogical stance which is bad because it won't happen And I can always dream.

now it comes out lol, ive been programming for several years seriously and now by default i am suspicious of my user input, almost paranoid. good code will be. regardless if the client is internal or external he is a client and therefore dumb and malicious by default.

Out of curiosity, what methods do you employ? In talking with a lot of Redmonites, including those in the Patterns & Practices group, I can't get a clear answer as to what they recommend. I'm actually going down to Dallas tonight to talk with them about it tomorrow.

If you look at the more significant shared/open-source codebases (e.g. Rotor, Exception/Data Application Blocks, etc.) it's clear they have an affinity for *some* form of precondition assertion. Here's a simple example in the Rotor implementation of the .NET Framework's System.String.Join:

public static String Join (String separator, String[] value) {
if (value==null) {
throw new ArgumentNullException("value");
}
return Join(separator, value, 0, value.Length);
}

and in the implementation of the JITer:

FJitContext::FJitContext(ICorJitInfo* comp) {

// To guard the cast to (bool *) from (BYTE *) in the calls to getClassGClayout
_ASSERTE(sizeof(BYTE) == sizeof(bool));

// etc.
}

Pretty basic, and largely preferential; however, I still wish a more "official" word from Redmond would be available so that developers had a practice that could be universally employed to riddle out some of the more obvious issues with user input.

 

[gopunk]

Originally posted by: Ameesh

Originally posted by: DWW
Yeah good advice all. Thanks for it. I'm trying to take coding more serious. I've been doing it 14 years but I'd say 12 of that was hobby and include basic, pascal, turing.

Trying to read into defensive programming and security now. I guess I take an idealogical stance which is bad because it won't happen And I can always dream.

now it comes out lol, ive been programming for several years seriously and now by default i am suspicious of my user input, almost paranoid. good code will be. regardless if the client is internal or external he is a client and therefore dumb and malicious by default.

yea what he said (and everyone else).

just to add two things...

1.) you never know how your code is going to be used. maybe now it's just you and your supposedly competant clients, but some intern at some point might decide to copy and paste some of your code, or whatever, for incompetant clients. you just never know, regardless of how sure you think you are that it'll never happen. (and client/user is anybody that uses your code, not necessarily a client in the business sense)

2.) private, etc... it's not like people decided to make this stuff for the hell of it. this is the result of experience of all the programmers before you. i'm sure initially, everyone thought like you did... that some degree of intelligence should be assumed as a given. but years and years of programming experience of hundreds of thousands of programmers has shown otherwise. why relive that painful history when you have the tools they've built to prevent otherwise inevitable tragedy?

 

[Ameesh]

Originally posted by: Descartes

Originally posted by: Ameesh

Originally posted by: DWW
Yeah good advice all. Thanks for it. I'm trying to take coding more serious. I've been doing it 14 years but I'd say 12 of that was hobby and include basic, pascal, turing.

Trying to read into defensive programming and security now. I guess I take an idealogical stance which is bad because it won't happen And I can always dream.

now it comes out lol, ive been programming for several years seriously and now by default i am suspicious of my user input, almost paranoid. good code will be. regardless if the client is internal or external he is a client and therefore dumb and malicious by default.

Out of curiosity, what methods do you employ? In talking with a lot of Redmonites, including those in the Patterns & Practices group, I can't get a clear answer as to what they recommend. I'm actually going down to Dallas tonight to talk with them about it tomorrow.

If you look at the more significant shared/open-source codebases (e.g. Rotor, Exception/Data Application Blocks, etc.) it's clear they have an affinity for *some* form of precondition assertion. Here's a simple example in the Rotor implementation of the .NET Framework's System.String.Join:

public static String Join (String separator, String[] value) {
if (value==null) {
throw new ArgumentNullException("value");
}
return Join(separator, value, 0, value.Length);
}

and in the implementation of the JITer:

FJitContext::FJitContext(ICorJitInfo* comp) {

// To guard the cast to (bool *) from (BYTE *) in the calls to getClassGClayout
_ASSERTE(sizeof(BYTE) == sizeof(bool));

// etc.
}

Pretty basic, and largely preferential; however, I still wish a more "official" word from Redmond would be available so that developers had a practice that could be universally employed to riddle out some of the more obvious issues with user input.

I use a similar method but i avoid using preprocesser functionality when i can. checking up on paramters right upfront is probably the best practice barring any special considerations.

there is no common standard of coding across all of ms, there are too many developers to try to enforce such a beast. but in the windows core group i would say that it is pretty common.

 

[Apathetic]

I completely agree with Descartes. You need to think defensively as a programmer. NEVER NEVER NEVER completely trust any input. If there was an agreed upon spec, (e.g. I'll never send you more than 2k worth of data) then you should throw an exception (and, if possible, log it) every time I do.

Dave