Silly C error cost me assignment marks!

[GodlessAstronomer]

Well I'm not too pissed because I still got 85% in a C assignment I handed in a couple of weeks ago. But I had missed a couple of classes and I didn't really put in enough effort to catch up, and a silly error cost me a bunch of marks in style.

When referencing members of structs I was using wacky pointer notation because I happened to have missed the classes on arrow notation. So if I have a struct named Person with an int age, I was referencing age using (*person1).age instead of person1->age

Stupid mistake! Sorry, this isn't really much of a programming Q&A type thread, just wanted to blow off some steam

 

[degibson]

You lost points for not using -> ? Thats asinine.
(*x).y is not wacky, nor wackier than x->y. You should go defend your assignment if it doesn't explicitly say to use ->

 

[Markbnj]

Holy crap, your professor is an anal retentive jerk .

 

[tatteredpotato]

Originally posted by: Markbnj
Holy crap, your professor is an anal retentive jerk .

My brothers prof spent more time teaching how to put in comments. He REQUIRED these ornate boxes of astrixs. They had to be a specific character width. He took off more points for minor formatting issues than for actual programming.

 

[seemingly random]

Originally posted by: GodlessAstronomer
Well I'm not too pissed because I still got 85% in a C assignment I handed in a couple of weeks ago. But I had missed a couple of classes and I didn't really put in enough effort to catch up, and a silly error cost me a bunch of marks in style.

When referencing members of structs I was using wacky pointer notation because I happened to have missed the classes on arrow notation. So if I have a struct named Person with an int age, I was referencing age using (*person1).age instead of person1->age

Stupid mistake! Sorry, this isn't really much of a programming Q&A type thread, just wanted to blow off some steam

I would think you should get extra credit for figuring out that (*strucp).ele is the same as strucp->ele.

You should send a copy to bjarne strousup.

 

[GodlessAstronomer]

Heh just reading my OP again I forgot to mention that I did this when referencing struct members through a pointer, although that was probably obvious to anyone who knows C

I might talk to the prof about this because I definitely did lose some marks so from what you guys have said it seems like somewhat of an arbitrary style guideline. Might get bumped a few points.

 

[Markbnj]

Originally posted by: ObscureCaucasian

Originally posted by: Markbnj
Holy crap, your professor is an anal retentive jerk .

My brothers prof spent more time teaching how to put in comments. He REQUIRED these ornate boxes of astrixs. They had to be a specific character width. He took off more points for minor formatting issues than for actual programming.

I'm all for adhering to common style guidelines, but I suspect that only in academia do you have the time and resources to obsess over every detail.

 

[DaveSimmons]

I wouldn't argue against the points lost. What you did is valid but not the normal way to access variables in a struct or class.

You made the code harder to maintain since co-workers (or you 6 months later) would have to put extra effort into figuring out whether there was some reason not to use the standard -> notation to access the variable.

If I were grading code, I'd also at least give a warning about this, or clever code that packs all of the code for a loop into the "for" line instead of the loop body, and tricky "if" statements that do too much before generating a true/false value as a side effect.

for ( -crazy long init calling functions and doing multiple assignments- ; -crazy long test where more functions are called- ; crazy long increment that does even more stuff instead of just an ix++ or i += n ) { ; }

if ( i = something_really_long (a, b, c, d, e, f, g, h, i, nested1( z, y, x ), k, l, ... ) ) { do something ; }

At work we often have to go back and update code that hasn't been touched in 6 months or more, so keeping the code readable is important.

The one I'd agree with is that 15-line decorative comment blocks are often silly. Give the function's parameters good names and have a 1-line comment that explains anything non-obvious.

 

[degibson]

Originally posted by: DaveSimmons
I wouldn't argue against the points lost. What you did is valid but not the normal way to access variables in a struct or class.

I disagree. Unless the assignment explicitly states that the -> operator is the 'normal' way (aka the appropriate style), then there is no 'normal' way.

 

[Markbnj]

Originally posted by: degibson

Originally posted by: DaveSimmons
I wouldn't argue against the points lost. What you did is valid but not the normal way to access variables in a struct or class.

I disagree. Unless the assignment explicitly states that the -> operator is the 'normal' way (aka the appropriate style), then there is no 'normal' way.

I tend to agree here. I think it's a stylistic choice, although I definitely prefer the simpler pointer notation as opposed to dereferencing it. I assume the compiler will generate the same code in both cases. My C++ is rusty, but I wouldn't think (*someptr).somefield would cause a copy or anything like that, right?

 

[Ken g6]

I agree with degibson and Mark. I would compare this to Perl's references. Perl needed pointers, but wasn't originally designed for pointers, so references are kind of tacked on. A Perl reference to an entry in an array can be specified in at least three ways:

${$aref}[1]
$aref->[1]
$$aref[1]

All are equally valid. So I don't think not remembering a shortcut should be a reason for deducting that many points, unless the assignment specified it.

 

[Cogman]

Originally posted by: Markbnj

Originally posted by: degibson

Originally posted by: DaveSimmons
I wouldn't argue against the points lost. What you did is valid but not the normal way to access variables in a struct or class.

I disagree. Unless the assignment explicitly states that the -> operator is the 'normal' way (aka the appropriate style), then there is no 'normal' way.

I tend to agree here. I think it's a stylistic choice, although I definitely prefer the simpler pointer notation as opposed to dereferencing it. I assume the compiler will generate the same code in both cases. My C++ is rusty, but I wouldn't think (*someptr).somefield would cause a copy or anything like that, right?

You are correct. The -> notation was just introduced as a short hand, much like += and -=. If that is the total reason that you lost points, then I would talk to the teacher about it. I don't think that either way is more readable (Ok, I lie, I actually prefer the way you did it as it shows what is REALLY going on).

If you lost a couple of points, but not the entire drop to 85, then I wouldn't care too much. The teacher probably said in class to do it that way.

 

[DaveSimmons]

Like I said, I'd have given a warning not points off if grading it myself, but if you look at published code in books and magazines you'll see foo->field1 is used 10 : 1 over ( *foo ) . field1 -- it is the more standard way of accessing class and struct object members for C/C++.

It would help to know if it was stated in the classes that GodlessAstronomer missed and/or in the class textbook that -> was the proper notation. If not in either then I'd agree that taking points off was unjustified.

Edit: though to contradict myself, "&" reference notation has been gaining in popularity so a fair amount of C++ code will now be

bool SomeFunc( foobar& foo )
{
foo.field1= bar ;
}

 

[seemingly random]

Originally posted by: DaveSimmons
Like I said, I'd have given a warning not points off if grading it myself, but if you look at published code in books and magazines you'll see foo->field1 is used 10 : 1 over ( *foo ) . field1 -- it is the more standard way of accessing class and struct object members for C/C++.

It would help to know if it was stated in the classes that GodlessAstronomer missed and/or in the class textbook that -> was the proper notation. If not in either then I'd agree that taking points off was unjustified.

I agree - except for the 10:1 guess. I would guess it's more like 10,000:1 or a million:1. When in doubt, choose the method which requires less typing.

Edit: though to contradict myself, "&" reference notation has been gaining in popularity so a fair amount of C++ code will now be

bool SomeFunc( foobar& foo )
{
foo.field1= bar ;
}

I'm not sure what is contradictory.

I rather like the availability of this notation. It indirectly enables specifying a read-only pointer which allows the optimizer to make assumptions. Plus, there's less typing with the . over ->

 

[degibson]

Originally posted by: seemingly random
Regarding the & operator
I rather like the availability of this notation. It indirectly enables specifying a read-only pointer which allows the optimizer to make assumptions. Plus, there's less typing with the . over ->

I, too, tend to prefer pass-by-reference const-ness:
void foo( const Obj &obj );

over bass-by-pointer const-ness:
void foo( const Obj* p_ojb );

However, like the other options we have discussed, they are equivalent. It all simply boils down to style preference.

In addition to (*x).y and x->y, Ken's post reminds me that there is also x[0].y, which is also equivalent.

 

[Apathetic]

Originally posted by: Markbnj

Originally posted by: degibson

Originally posted by: DaveSimmons
I wouldn't argue against the points lost. What you did is valid but not the normal way to access variables in a struct or class.

I disagree. Unless the assignment explicitly states that the -> operator is the 'normal' way (aka the appropriate style), then there is no 'normal' way.

I tend to agree here. I think it's a stylistic choice, although I definitely prefer the simpler pointer notation as opposed to dereferencing it. I assume the compiler will generate the same code in both cases. My C++ is rusty, but I wouldn't think (*someptr).somefield would cause a copy or anything like that, right?

I completely agree with you and degibson. In C, using someptr->somefield instead of (*someprt).somefield is pure syntax sugar - i.e. they are logically equivalent and generate the same code.

A friendly comment from the professor about that fact would have been approprate. There is no sane reason for the OP to have lost points on this.

Dave

 

[VinylxScratches]

I've never really programmed in a corporate environment except with another intern with no guidance from other programmers but what about programming standards? Do companies choose what syntax to use in their programming guidelines? Maybe that's what the teacher is trying to do?

 

[dighn]

Originally posted by: VinylxScratches
I've never really programmed in a corporate environment except with another intern with no guidance from other programmers but what about programming standards? Do companies choose what syntax to use in their programming guidelines? Maybe that's what the teacher is trying to do?

Workplaces often do have enforced coding standards. The question is, did the prof make clear what his/her expectations were? But of course it's also a moot question, because it's school and so the prof is always right.

 

[Madwand1]

Better you learn a lesson losing a few marks in a school assignment than have your professional peers thinking that you coding style sucks.

 

[Bulldog13]

Originally posted by: ObscureCaucasian

Originally posted by: Markbnj
Holy crap, your professor is an anal retentive jerk .

My brothers prof spent more time teaching how to put in comments. He REQUIRED these ornate boxes of astrixs. They had to be a specific character width. He took off more points for minor formatting issues than for actual programming.

I'll tell you what though, there is nothing like opening a foreign code base and seeing the queer asterisks. It usually means maintaining someone else's code won't be the blunt trauma to the head it normally is.

 

[degibson]

Originally posted by: Madwand1
Better you learn a lesson losing a few marks in a school assignment than have your professional peers thinking that you coding style sucks.

Regardless of how good a coder you happen to be, this will always happen eventually. Some jerk will always have bad things to say, even about good code. The truth is, we can't all be good coders... and bad coders try to make other coders look bad so that they suck less by comparison.

On the other hand, a good coder can readily adapt to equivalent syntax. If you have trouble with (*x).y vs x->y vs x[0].y, then you're relying too much on the syntax to understand what is going on.

EDIT:
OP: Don't let naysayers distract you from going to your instructor, if the assignment didn't specify which operator to use. You can make lasting contacts by arguing your points well, even early in your education/career.

 

[DaveSimmons]

On the other hand, a good coder can readily adapt to equivalent syntax. If you have trouble with (*x).y vs x->y vs x[0].y, then you're relying too much on the syntax to understand what is going on.

It's not whether you can figure it out, it's how much extra time will it add to maintenance work if people used nonstandard but legal syntax in their code. Using nonstandard or clever syntax instead of a consistent and clear standard code also increases the chance of code changes introducing a bug.

 

[Markbnj]

Originally posted by: DaveSimmons

On the other hand, a good coder can readily adapt to equivalent syntax. If you have trouble with (*x).y vs x->y vs x[0].y, then you're relying too much on the syntax to understand what is going on.

It's not whether you can figure it out, it's how much extra time will it add to maintenance work if people used nonstandard but legal syntax in their code. Using nonstandard or clever syntax instead of a consistent and clear standard code also increases the chance of code changes introducing a bug.

I can't disagree with that at all, but the fault probably lies more with the language designers. If you give people tools they'll use them. I know guys who use lambas and anon delegates in their C# code every single place they can possibly make the syntax work, even when there are older, and admittedly more verbose, ways to get something done. I like simple languages, which I why I still look back fondly on assembler.

 

[degibson]

Originally posted by: DaveSimmons

On the other hand, a good coder can readily adapt to equivalent syntax. If you have trouble with (*x).y vs x->y vs x[0].y, then you're relying too much on the syntax to understand what is going on.

It's not whether you can figure it out, it's how much extra time will it add to maintenance work if people used nonstandard but legal syntax in their code. Using nonstandard or clever syntax instead of a consistent and clear standard code also increases the chance of code changes introducing a bug.

I agree with the assertion that use of a common syntax subset is useful for maintainability between coders, esp. in a large organization, but I disagree with the use of the word 'standard' in this context. All of the above methods are part of the C standard. Specifically, there is nothing above that is non-standard.

Preference of one method over another may be, legitimately and for good reason, part of a style guideline.

 

[Madwand1]

Originally posted by: degibson
Regardless of how good a coder you happen to be, this will always happen eventually. Some jerk will always have bad things to say, even about good code. The truth is, we can't all be good coders... and bad coders try to make other coders look bad so that they suck less by comparison.

We're talking about coding style, not code quality in depth. Everyone can have good coding style if they give a damn, and losing marks in a school assignment over silly style issues is a lesson in giving a damn.

I'd agree that an isolated choice of (*). vs -> is not something to get up in arms about, especially in a professional context, but if you're deliberately choosing (*). over -> everywhere, you'd better be able to back it up with a good reason -- better than the "sorry, I missed / didn't know that" defense of the OP.