|
|
Sander Rossel wrote: I've definitely worked with code from developers who did not enjoy learning
{
Allow me to be the jerk who says I don't consider them to be developers - at least not competent ones. :~ I could just be being extreme and judgmental though. But I've never worked well with them.
}
Sander Rossel wrote: I rarely learn just for the sake of learning.
{
Maybe I'm just an oddball then. It wouldn't be the first time.
}
Sander Rossel wrote: Since I'm a good friend I want you to learn, so I've compiled one of the best learning resource for you to check out: hidden learning surprise inside!!![^] 
{
As you can see, I've taken it to { heart }
At least you didn't Rickroll me. =D
}
Real programmers use butterflies
|
|
|
|
|
{
This is more than I ever hoped for!
}
|
|
|
|
|
I did read that article though, and the main point is the same one I think you made, that what if:
if(foo)
bar();
baz();
To which I respond that this has never happened to me that I can recall, in part because VS autoformats code and I hit Ctrl-A,K,D regularly.
So it's a solution in search of a problem, at least with my personal code.
When I am working on a team I code differently, but it also takes me longer and irritates me.
Real programmers use butterflies
|
|
|
|
|
I just found an abomination, purely by coincidence, that had me confused for a moment.
if (something &&
somethingElse)
DoStuff();
else
DoOtherStuff();The indentation doesn't help here!
Needless to say, I wanted to add braces and added them above somethingElse, which broke the code 
The point you make has actually happened to me before.
I inherited someone else's code and I had to make a change.
For some reason, the original programmer added two lines with the same indentation (and VS didn't change it back for me, I think this was VS2010).
I added a (conditional) third, but to my surprise it was always executed!
Took me a while to find that one 
|
|
|
|
|
awwwww.
Well maybe its your else statements that are the problem!
Don't use else {}[^]
Real programmers use butterflies
|
|
|
|
|
Having multiple return statements in a function is another pet peeve of mine.
I'm fine with it at the start of a function, like if (parameter == null) return, but not somewhere halfway.
I read some code at the top, miss the return statement in the middle, and think I'm getting a wrong result at the end.
Only when I actually run the code (and somehow my breakpoint won't hit!) will I see the error in my thinking because the functions returns on me halfway.
I recently read some sample code that had like four return statements in some 20-25 line function or something, that's just plain not readable! 
Also, what if my else branch doesn't have to terminate the code? 
|
|
|
|
|
To be fair I don't agree with that article.
But I also feel like creating workable (as in readable/maintainable) code is an organic process. If you try to force it it impedes productivity and becomes counterproductive. I think at least, unless you need (and are willing to spend the overhead) to work in a mid to large team it's different, but on my own or in small groups it's in my experience best to let experience teach you how to code, and say screw the thinkpieces that people write simply to make themselves seem smart. For different people what maintainable readable code looks like is going to be different, but find something that works well *for you* and do that.
I never get tripped up on braceless ifs, so it's not a peeve of mine. I however, *loathe* over factoring, such as using design patterns just to use them, or creating a class where one function would do. Why? Because I find it impossible to navigate.
But you know what? That code can map directly to a UML diagram and my code can't, so I should drink a tall frosty glass of STHU because that code has its advantages.
I also don't like interfaces i am expected to work against to come without XML DOC COMMENTS!!
But that's because i have to work with that code. Otherwise I could not care.
My point is, we all have our peeves, and different styles and such, but unless i have to code against your work I don't care what it looks like. I hope *you* do though, if that makes sense.
Real programmers use butterflies
|
|
|
|
|
"We are what we repeatedly do. Excellence, then, is not an act, but a habit." - Not Aristotle, apparently
That only goes for my style though.
The actual program tends to change and I change my view of how I want my code to flow.
For example, a program I made three years ago still has the traditional three tier architecture.
It's completely over factored I think (now, it made sense three years ago).
I have one tier that gets entities from the database and puts it in domain classes (not entities, those are DB specific) and then the middle tier passes it on to the controller and the controller translates it to a view model.
The middle tier is completely empty most of the time and the domain classes don't do anything either.
It's just there because
To make things worse, since it's all pretty much the same code, I've created some generic base classes that create generic expression trees, so that my data layer can generically query any entity.
I may have gone a bit overboard on that one
My code from last year follows a simpler design, entities are translated directly into view models (and vice versa) and it all happens in the controller.
I still have some generic code, but not in my database code.
I prefer copy/paste and seemingly duplicity in the name of maintainability.
My past project has taught me that just because I have the technical know-how does not mean I have to use it
I've also been told ex-coworkers (especially the anti-learn) still struggle reading my code (so it's totally worth it!)
The fun part is, that when you look at my naming conventions, member placement, project and class layout, etc. nothing has changed in those past few years
honey the codewitch wrote: unless i have to code against your work I don't care what it looks like. I hope *you* do though, if that makes sense.
I know what you mean.
I do care about what your code looks like.
I go to bed with it and I wake up with it.
Those darned braceless if-statements!
Or maybe that wasn't what you meant... 
|
|
|
|
|
You are too funny. I mean that. Too funny by half. 
I want people to take pride in their own code. If they do, and they respect the craft their code will reflect that, style differences aside.
That's what I meant.
Real programmers use butterflies
|
|
|
|
|
Believe it or not, but I actually knew what you meant.
I'm just trolling you
|
|
|
|
|
Enough of this gabfest! Don't you lads have any work to do?
And for the record, @code-witch, I'll also use a braceless if, and even if-else, but it depends. A simple
if(condition)
statement1;
else
statement2;
is perfectly clear to me.
I'm so thoughtful, injecting new life into your thread.
|
|
|
|
|
Greg Utas wrote: Don't you lads have any work to do?
On a Sunday? No
Greg Utas wrote: I'm so thoughtful, injecting new life into your thread.
But do you really want to get involved?
Too late for that, you're a part of this now.
Prepare to be pitchforked!
|
|
|
|
|
"are there no workhouses?"
Alright Scrooge, it's Sunday!
Real programmers use butterflies
|
|
|
|
|
Oh I know. It's much more difficult for you to if I treat you like you're not.
Real programmers use butterflies
|
|
|
|
|
if(foo)
bar();
baz();
In Python not...
M.D.V. 
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
Perhaps ironically that's actually the reason I will not use python. I'm serious.
Real programmers use butterflies
|
|
|
|
|
honey the codewitch wrote: Perhaps ironically that's actually the reason I will not use python. I'm serious.
I feel your pain and share your concern.
And I am serious too.
M.D.V.
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
This thread really is really resonating with my experiences, both good and bad ones. I'll try to sum up my experience so briefly:
First the bad:
The toxic 'anti-learn' folks are around, with so many variances. I try to persuade them to find joy in their work, but to them it's "...just my job, I'll get what I have to do done and then go home and not think about it". Never learn anything new unless they're explicitely directed to use it. Or "...I just have to do this for ten more years and then I can retire...". They'd be wiser to change their careers now when they're still young enough to live life. I'd rather be dead already if I was in their miserable state.
And the best!
The learners, the knowledge-sharers! These are the people in techie careers of all types (and then again, not necessarily techies) They are a joy to know and work with! Something new comes their way and they willingly share it, or they seek out their coworkers/neighbors/friends. They share in the fun you have of learning too. Keep in touch with these folks. You can always get joy from learning, even if it doesn't pay dividends!(e.g. even learn to juggle!)
A teacher in high school told me to never stop learning, never stop reading things, keep connections that matter. It was the best advice I ever got.
|
|
|
|
|
Pete Kelley wrote: The learners, the knowledge-sharers!
I've been this in an organization full of
Pete Kelley wrote: The toxic 'anti-learn' folks
I regularly posted about new stuff on the internal Yammer channel, but I barely got responses.
Then I posted something about Cobol and how it wasn't dead and I got more likes than I've ever had before
|
|
|
|
|
I was trained in the late 60-ies and early 70-ties, and then - of course - doing computers and computer science was an adventure. Developments were going fast, languages were being developed and explored. Compiler construction was a real challenge then.
The last 20 years of my professional life I was in a more managerial role, buto boy, you can learn a lot then! about people, politics and organizations.
After retirement I picked up programming again, and it is really different from the days of working on a PDP-9 or 11. But, as long as there is a clear view of what I want to make (I am afraid it is more the technical stuff) I really enjoy learning about Fourier, Laplace Javascript, PHP , C++ and ....
So, yes I understand what you are saying, and I think it is a wonderful attitude
|
|
|
|
|
Time to transition to the "teaching rush".
|
|
|
|
|
I try. Look at my article count here.
Real programmers use butterflies
|
|
|
|
|
Not just that, but also actual teaching with students around. Clearing their doubts, and resolving their issues.
|
|
|
|
|
I'm not able to do that anymore. A few years ago I went over the high wall and since then people freak me out, especially lots of them in one room. 
Real programmers use butterflies
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
