[baavgai]

lesPaul456, on 10 February 2010 - 07:46 PM, said:

I noticed that most people who started with C++ programmed so much differently.

You've been hanging out with a limited C++ crowd. ;)

First, there are two style elements here, brace and case. The C# usage of Pascal case for methods is unusual for the curly brace languages. Aside for that, every other element reflects common C/C++ style elements. More info here.

My C# code looks like:

public void SomeMethod() {
    // Some code
}

[LetMeFinclOut]

Probably off-topic, but this reminds me of an Agile technique called Pair Programming (2 people sharing 1 machine to write code).

Has anyone here done such a practice? I can't see the value in it as it seems that people would just but heads as described above. Sure, the second person would catch a few things that the furst one didn't, but wouldn't a standard code review accomplish the same thing? Seems to me like you're paying 2 people to accomplish the work of 1.5.

[Topher84]

The main reason for pair programming is to catch errors. You will most likely be paired with someone on the same skill level that you are. The complaining about spacing, braces, etc... like someone said previously, should be covered in your standards given to you by the company you work for. In an academic setting, most university CS departments should have a set of standards which everyone is to adhere to. The main issue in an academic setting, is that most professors within the department probably don't enforce those standards. This is purely my opinion, but the general introverted mindset of most programmers causes the "anal retentive" mode. Rarely can you find two programmers in an academic setting who can get along with each other well enough to pull off pair programming without some serious whining involved. If your professor is doing this, they are most likely training you to leave your "shell" and be a little more extroverted.

[solo321]

I think programmers have their own original way of coding. They like the way they do it and they want it to look like their way. When she does it her way, yes I agree its not as efficient as the normal way, but it gets the job done. Code is sorta like an art. There are MANY ways to code the same thing and everyone has their personal preference. Usually there alot similar than the situation you are in haha.

[beju0506]

I don't mean any disrespect by this, but I can't stand doing group projects with people that act the way you described. The entire point of having a group exercise is to have everyone compromise on a solution, not to have one member take over and micromanage the way other people code. I've had this happen numerous times in group assignments and unfortunately for everyone else, it's usually the person who codes the most poorly who is the most domineering about making the project go the way they think it should be done. (I'm not casting dispersions on you, MacOSXNerd, just making an observation about my own experiences.) It seems that programmers tend to be "individual-work" type people who are prone to thinking their way is the best way, no matter what. However, I think it's important to understand that group work helps get you out of that "I know what's best" mindset and open to new ideas. You may not like the way other people code, but they have (I'm making an assumption here) the same seniority level that you do, so they have just as much of a right to their opinion as you do to yours. (Again, I'm not directing this toward MacOSXNerd, just making general observations about programmer interactions.)
Just my $0.02. :)

macosxnerd101, on 10 February 2010 - 01:47 PM, said:

When it comes to my programming projects, I'm not just controlling with my code, but everyone else's as well (unless the instructor says, each person write a method. in which case, so long as the components work, I'm not going to complain). I am very much of the mindset if you're going to do it, do it right or kindly gtfo (and yes, that's what she said).

[kingfeanor]

I think your teacher needs to realize that working in teams is not the same as paired programming. I have been an engineer in a corporate env (200+ developers at my site, tens of thousands worldwide) for 5 years now and have never shared a computer with anyone.

Real life teams divide work. So I might be adding new functionality to code someone else wrote, producing classes, web services, libraries, etc. that someone else consumes and consuming someone else's classes, web services, libraries, etc all at the same time. We check code via code reviews. The software to do this is part of our version control system. After I check code into my branch, I create a review of those changes and send to others. They can flag bugs, make comments, etc. and I must fix issues before that code can be promoted to the stable or main branch.

My experience has been that there is a document somewhere that defines what the format of source code should be, how variables should be named, etc. Sometimes, if you are using a tool like Eclipse, there may be templates for the auto code generation which have been tweaked to format things according to the standard. Most likely there is also a development best practices document which talks about the ways one should structure code, use of design patterns, deal with cohesion and coupling, 3rd party libraries, internationalization (using unicode strings, etc.), logging, security (validation of inputs, use of unguarded buffers, etc.), source management and so on.

Most college professors (at least the ones I had) never have developed in a corp env and don't have a clue about all this stuff. Be ready to conform to the expectations of the team you join when you get a job and don't think your college experience is anything close to real world.

[Programmist]

macosxnerd101, on 10 February 2010 - 02:47 PM, said:

When it comes to my programming projects, I'm not just controlling with my code, but everyone else's as well (unless the instructor says, each person write a method. in which case, so long as the components work, I'm not going to complain). I am very much of the mindset if you're going to do it, do it right or kindly gtfo (and yes, that's what she said).

I think you'll find this attitude won't serve you well in the working world. On a team it is each individual developer's responsibility to follow coding standards. Enforcing those standards should be handled by management (or designated mentors) through code review and/or code quality management software.

[Programmist]

nbroemm1, on 10 February 2010 - 01:00 PM, said:

I have been programming for about two years now, basically when I started college. All I hear from my professors is that programming in the real world is working in teams or with other people to complete projects...

I have to agree with some of the previous posters. Pair programming (and XP as a whole) is not the norm. Unless you are working on the same machine it's very unlikely that you be working on the same function/method as someone else. For the most part work is modularized at the class/file level or higher. Any smaller and you might end up with SCM merging nightmares.

[Harlen]

My other classmates don't even pay attention. The teacher actually had to take away from our free-time to work on assignments to read aloud with her from our book. I HATE it! It doesn't help the other students at all, and it completely wastes my time, because I simply cannot learn like that.

Also, when they try to get help from me, I do ALL the work. They don't even know what they're doing, yet they choose to remain in this accumulative class when it's a new semester...

I'm am one of the few in my class that is actually making an effort to study Java.

[galorin]

As far as my own experience goes, which isn't much mind you, some people just can't think logically. It can be learned, and it can be taught to many though.

There are only 2 of us programming, and we have 3 other people with direct influence on the project. We have rough style guides and standard practices which need to be adhered to. One of which is all if style statements must use braces and tab indentation. The other is all variables must be documented above the function they are used in, and declared at the top of the function. Initialisation happens next. Our main rule is that global variables are evil and must not be used.

We've both broken these rules on occasion, there are a couple perl style one-line if statements, and I've been forced to create global pointer arrays because of how someone else set the software up (No one on the current team mind you).

It may be worth coming up with some best practises between you and your disorganised partner. Just some basics, like where to declare and initialise variables, as well as when and where to comment code.

[SpectateSwamp]

You'll work in teams if you are training or being trained.
I was training a couple of programmers how to do Cable system billing conversions. On the final project where I worked with them. (from 3000 miles away) I had a conversion to do that came from the same billing system. 2 weeks before the conversion I got their code to use for my data. I could hardly understand it but was prepared to go with it. The day before the conversion was due they sent me an update set of code. It looked just like I would have written it. It nearly brought a tear to my eye. Nearly. I was so proud of them.

As for profs knowing anything about the real world. They don't. I was at a christmas party with 2 new staff. (both PHD's) They had taught for 10 or 15 years. I had WORKED in the RW for that many years. They knew that they wouldn't hold a candle to me when it came to completing projects.
Coding styles and standards don't matter at all. Execution speed isn't a problem and hasn't been for 30 years. Phooie to coding standards.

P.S. I learned one of the best coding tricks from a Poor fellow that was laid off a short time later.
Also if it isn't broke don't fix it. You perfect perfects are all the same.

This post has been edited by SpectateSwamp: 12 February 2010 - 07:07 AM

[macosxnerd101]

@beju506: In my experiences, I tend to have the opposite situation, where my team mates have the need for me to babysit (as in, they won't do any work or aren't proficient enough to do so, to the point where I have to go back in and re-write their code). When it gets to that point, that's when I start being super-controlling. However, if my team mates are relatively proficient and can accomplish their tasks, that's even better so that I can focus on writing my part to the best of my ability.

@Programmist: You're absolutely right, though I'm not at that point yet as I'm still in high school. Generally, the problems I have with others' code come across at the time of integration when their code is unusable (as I said before, if it works, then I generally could care less how they did it), and I have to re-write it at 1:00 AM on a last minute notice.

[Pwn]

SpectateSwamp, on 12 February 2010 - 08:06 AM, said:

P.S. I learned one of the best coding tricks from a Poor fellow that was laid off a short time later.

Spaghetti, PHOOIE!

spaghetti leads to layoffs, see your comment above.

[anonymouscodder]

Programmist, on 11 February 2010 - 05:41 PM, said:

Unless you are working on the same machine it's very unlikely that you be working on the same function/method as someone else.

Exactly. When it's a one person task the style doesn't matter, otherwise the project must have a pattern to be followed.

[ladyinblack]

Well, I remember when I was in school, we were never forced to work in teams for a project, however, I was always the one everyone called if they could not figure out why their program ain't workin.

The strange coding structure I saw, WOW. But, what I'm trying to say is, you will have to be tolerant. If you think a two line statement can be a one line statement, rather show that person that this could also work, nevermind the way the program is structured. It is probably the way she understands her coding. But, if you get commented on your coding structure, then you got a chance to change a few things towards your style.

The other thing is, if you are ahead, you could try the program at home, away from the teaming up, then that gives you a head start and not worry too much about the other person's programming style.