The problem is I can't really show you the code I'm working on now. If I come across good examples as I'm working the Open Source stuff, I'll definitely post them.

The only specific example I remember was this:

Surely, we can agree that if someone has gone to the lengths of creating this method their other code isn't very good?

We need a reality show where programmers are locked in a house for 90 days to fight over coding conventions.

Yeah, definitely. I actually think we were really just talking past each other a bit and we have slightly different levels of annoyance with different types of bad code.

On a random note, I will probably never again use Stored Procedures in a meaningful way. For larger projects they're a ****ing nightmare to update in a sane way.


Disclaimer: I'm one of those people that overreacts to bad past personal experiences.

shabby,

wait, you have a problem with setters? would you prefer that member variable x be public so that you can manipulate it directly instead of via a setter, or do you have some other solution to this problem?

I never really use SP, I'm quite embarrassed about it because I was under the impression everyone uses them as standard. I just find it way easier to maintain in the code as queries.

+1 on avoiding sprocs unless you've got a really damn good reason to use them. ime, the sprocs are often not even under revision control -- talk about a problem with readability!

also, unit tests. your dba is totally using StoredProcedureUnit for his work, right?

i would totally watch this. we could call it HU4CODEZ.

this idea already better than 90% of the shows on G4 (sorry, "code monkeys", i really tried to like you).

Take another look at that code.

Edit: Although I actually do think getters/setters/private member variables are almost always overrated (to be clear NOT useless). Python seems to get along fine without it.

speaking of which, i've been obsessed lately with jonathan coulton - code monkey (yes, i'm like three years late to this party). i keep waiting for an opportunity to tell my manager to do goddamn login page himself.

not seeing it. it could be called setX instead of setVariableX? i must be missing something dumb.

pretty tough to do true, compiler-enforced encapsulation without private member variables and it's even tougher to work with private member variables without setters/getters. i think encapsulation is useful enough to validate the extra hoops, especially in large code bases where it's hard to track who is using what when.

It's a private function.

I use to believe this fairly strongly. After working with Python a lot I'm much less sure.

:facepalm: that is confirmed ******ed (both me and the code).

have you worked on a python code base that was sufficiently large and OO enough to reap the (supposed) benefits of that kind of strong encapsulation? me neither .

fwiw re: SP i was going to make a "1995 called, it wants its web development technique back" joke, but then i figured since i havn't used them in 10 years i really dont know what i'm talking about so i better not.

Indeed.

Any of you experienced with freelance work give me any advice is appreciated:

http://forumserver.twoplustwo.com/30...blems-1084746/

I'm so lost

That sucks. I would cut them off and give them a number they have to pay you for you to keep working, whether that's 50% of 75% of 100% I don't know, but I'd do at least 50% if I were you. The squeaky wheel gets the grease.

In my defense, I was purposely creating bad code. If I recall my question correctly, I was using two extremes to ask where the middle is, not "Look at how much awesome I am!"

I am sad that people would use that stuff in the real world, but whatever.

/defensiveness

gull,

that sucks, but it's time to play hardball. withhold the demo until you get paid.

daveT, I was actually giving you a compliment.

fair enough. i'll have to poll some of my colleagues about the cost vs value of encapsulation and private variables. we're a c++ shop though, so "doing stuff so that the compiler can tell you before you shoot yourself in the face" has a higher value than it might in other languages.

i did think of a use case for your private setter example, though: if you're using a weakly-typed language that allows enforcement of types on method arguments, then your example is shorthand for writing this a bunch of times:

thanks, i'm here all week. pm me for consulting rates.

Hah, I actually saw the method and was like "Oh, they must be doing some sort of validation checking."... then I saw the implementation and was super annoyed.

What do you guys think about passing variables by reference in C++? Specifically primitive types (int, float, etc.). Personally I hate it, because as my eyes scan code, if I see an int being passed into an assumption like

doStuff( x )
instead of
doStuff( &x)

my default reaction is "oh, it looks like it's being passed by value so there's no way this function will change the value of x." Then I see that the function is declared as

void doStuff( int& x );

and I feel programmer rage building inside of me. Is there a good reason to do stuff like that instead of just using an integer pointer?

Maybe it depends on your environment...most of our codebase is C, so uses like this are pretty rare and seem out of place.

Yeah, it's bad. This is command/query separation which Martin discusses in Clean Code.

http://en.wikipedia.org/wiki/Command-query_separation

I will very rarely pass variables by reference (not C++, but it's hardly language specific). I use it in very specific situations - such as a method that needs to alter multiple variables. I also comment the poop out of it, because the reason I'm doing a function instead of a new class is because it's something I'm factoring out of a method that doesn't necessarily need a new class.

Although, now that I try to defend my actions, I realize that I should just stop being so ****ing lazy and make a new class for it.

In conclusion: it's probably something that is almost never a good idea, and when you do it, you can probably find a better solution.