The hardest part about programming is conceiving ten perfectly good ideas and throwing nine of them away.

-Josh

-Josh

<snip source="wikipedia">

Hoc and Nguyen-Xuan define computer programming as "the process of transforming a mental plan in familiar terms into one compatible with the computer."

</snip>

Hi, I'm ScanIAm, I'm a GoldPlateAholic.

15 minutes ago, MasterPie wrote

That empty feeling inside when you have to defer to code you did not write.

++

-Josh

58 minutes ago, JoshRoss wrote

@brian.shapiro: I think that I understand where you are going. If you were to split the world into two parts, finding the problem and offering a solution, what would you call the later, in terms of a process?

-Josh

<snip source="wikipedia">

Hoc and Nguyen-Xuan define computer programming as "the process of transforming a mental plan in familiar terms into one compatible with the computer."

</snip>

 

What would you say the difference is between coding and programming? In my view the two are pretty similar concepts.

Design is about working out the interface -- whether thats the user interface, some cross-application interface, the interface of the different parts of one program, or different processes of one function. Programming is going about and implementing that design. I consider it to be more about knowing a skillset than about creativity, its the most tedious and boring part of making a piece of software.

1) Taking up the courage to start from scratch.

2) Resisting the urge of doing that endlessly.

14 hours ago, brian.​shapiro wrote

What would you say the difference is between coding and programming? In my view the two are pretty similar concepts.

Design is about working out the interface -- whether thats the user interface, some cross-application interface, the interface of the different parts of one program, or different processes of one function. Programming is going about and implementing that design. I consider it to be more about knowing a skillset than about creativity, its the most tedious and boring part of making a piece of software.

 

I'm not completely sure where I fall on this. Coding seems like writing a snip-it, when I see coding, I think Coding Horror.

As far as how I think how design and programming fit together, I feel that design is when someone else does that part. IMHO, when you are a one man show, it's all programming.

-Josh

And... working with people who re-write everything in the most overcomplex, academic way because someday you are gonna need to that way -- you know just in case you decide to replace x with y -- and yet never seem to get anything done. I'm all for seperation of concerns and each layer performing a specific role but sometimes people get too carried away -- especially those who suffer from the "not invented here" syndrome. 

You know this post has inspired me... I think I'm gonna start a new blog named "Breast Practices" where I mix some common sense programming techniques with some mouth watering pr0n.

Seriously, though, I get your point about overcomplication.  Stuff like NInject and MSFT's Unity are useful tools if you need to unit test parts of the application, so I do understand their usefulness, but I've seen them seriously overused on projects.

Oh, and another 'hardest part' is coming in to a project after a number of 'clever' folks have had their way with the design and chose not to document what that design was.  Spending a few months feeling like an idiot while you try to wrap  your brain around their 'clever' coding is a giant suckfest.

4 hours ago, ScanIAm wrote

@DeathByVisualStudio: I would like to subscribe to your newsletter...

Seriously, though, I get your point about overcomplication.  Stuff like NInject and MSFT's Unity are useful tools if you need to unit test parts of the application, so I do understand their usefulness, but I've seen them seriously overused on projects.

Ah yes. I spent a week ripping out the enterprise library where somone decided to use it for the factory pattern, despite there only being one type of each class in each factory. *cry*

But yea, for me YAGNI is a constant problem.

Resisting pressure to 'just get it done' and making sure it gets done to a decent standard.

12 hours ago, earnshaw wrote

Without using a OUIJA board, trying to divine your predecessor's intent when he wrote that glop.  Also, trying not to become violently ill when confronted with what passes for "documentation."

For the most part, programmers write poor documentation. Do you think having Microsoft provide a certification for documentation, would improve the situation?

-Josh

This is usually a symptom for me of developers re-inventing the wheel. If a library exists that does what you want, re-use it. I come across far to many developers that want to write everything themselves, all because they don't want to have to learn how someone else solved a particular problem

5 minutes ago, vesuvius wrote

@Bass: --

This is usually a symptom for me of developers re-inventing the wheel. If a library exists that does what you want, re-use it. I come across far to many developers that want to write everything themselves, all because they don't want to have to learn how someone else solved a particular problem

At times I've re-written something that was already developed, but because I understood how they solved the problem, I just thought it was done in a really horrible clumsy way.

The truth is that the clever folls are usually not that clever. I see this constantly where some highly qualified and educated developer opts to always take the complicated route, simply because solving problems the simple way is something they cannot do. It is now why I almost always insist on having graduates and prospective developers write code as part of the application process. If I could I would have an apprectice style recruitment process nd hire people after seeing them solve several stories. The best qualified developers are sometimes guilty of creating the most abstruce code bases

Technical debt is a real problem in Agile development, and refactoring is a must. As Dr Herbie intimated, it a matter of negatiing that need to rewite just for the sake of a re-write.

C

I've found, though, that it's a bigger challenge to take complicated code or business rules and make them as simple and clear as possible.  Every bit of scaffolding you can remove makes the app smaller, faster, and easier to improve upon later when you actually do need the clever bits.

6 hours ago, vesuvius wrote

@Bass: --

This is usually a symptom for me of developers re-inventing the wheel. If a library exists that does what you want, re-use it. I come across far to many developers that want to write everything themselves, all because they don't want to have to learn how someone else solved a particular problem

Not all code out there is worthy of [re]use.

-Josh

1 day ago, ScanIAm wrote

@DeathByVisualStudio:

*snip*

Oh, and another 'hardest part' is coming in to a project after a number of 'clever' folks have had their way with the design and chose not to document what that design was.  Spending a few months feeling like an idiot while you try to wrap  your brain around their 'clever' coding is a giant suckfest.

OMFG! This is the story of my life right now to a T. "Self documenting code" -- now there's a joke.

It's talking to other people (managers) about programming. It's like trying to learn a donkey how to ride a bike.

Then some technical problems: dealing with obsolete modules and programming models; dealing with unstructured/non-modular/monolithic undocumented code ("ok" for code to be unstructured and documented or structured and un-documented, but not both); promoting quality code with an outdated tool chain (often can't use .NET and VS).

1 day ago, JoshRoss wrote

 

*snip*

For the most part, programmers write poor documentation. Do you think having Microsoft provide a certification for documentation, would improve the situation?

-Josh

 

 

Have you read some of the MSDN documents?

No I don't think that would help all that much...

1 minute ago, Maddus Mattus wrote

My code documents itself

My code obfuscates itself

11 hours ago, harlock123 wrote

*snip*

Have you read some of the MSDN documents?

No I don't think that would help all that much...

You hit the nail on the head with that one. I think the problem lies with automatic generated documentation. If it wasn't automatically generated, then I guess someone would have to actually write something about what all these classes are for and what the methods do.

I wonder if the content would be better if people had to pay for it. Surely, Jaron Lanier would have something to say about that.

-Josh

Clean code shouldn't need comments. The only time you should use comments is if your code is doing something extremely strange and you couldn't figure out any clean way of doing it.

-Josh

1 hour ago, Bass wrote

Comments are often used as a crutch for sloppy code. Comments can also and often lie, they are ignored by the compiler and thus can say anything no matter how incorrect. Code can not lie. It does what it says.

Clean code shouldn't need comments. The only time you should use comments is if your code is doing something extremely strange and you couldn't figure out any clean way of doing it.

I'll bet the guy who wrote the 10 year old C++ code I am debugging for memory leaks thought it was obvious what he was thinking, when he wrote it.  Alas, no documentation *at all*.  A whole load of low level memory manipulation to fit into one can only presume was 640K of memory ... <sigh>.

4 hours ago, Bass wrote

Comments are often used as a crutch for sloppy code. Comments can also and often lie, they are ignored by the compiler and thus can say anything no matter how incorrect. Code can not lie. It does what it says.

Clean code shouldn't need comments. The only time you should use comments is if your code is doing something extremely strange and you couldn't figure out any clean way of doing it.

I've always found people who don't like to comment their code also don't like to test their code and rarely like to use anyone else's code. It's obvious isn't it?

I guess I don't own an iPhone...

1) code blocks (maybe.  And if you do, don't just repeat the code, describe what it does.)

2) methods and parameters

3) Anything that isn't extremely clear

Oh yeah. A lot of times someone comes in and just break it because they didn't know WHY. Althought usually a good Unit Testing can prevent that.

I usually comment block by block to explain the purpose of each block. So I would know a general implementation flow of a particular method.

1 day ago, Richard.Hein wrote

*snip*

I'll bet the guy who wrote the 10 year old C++ code I am debugging for memory leaks thought it was obvious what he was thinking, when he wrote it.  Alas, no documentation *at all*.  A whole load of low level memory manipulation to fit into one can only presume was 640K of memory ... <sigh>.

Well you are debugging poorly written code. If the code you are reading is hard to understand, that's the code's problem. I stick to what I said: clean code doesn't need (and shouldn't have) comments. Why? Because clean code is ALWAYS understandable in it's own right.

Define "Clean Code".

I did a simple loop of for(int i=1; i<n; i++) and there is an important reason why I do it from 1 instead of 0. No comment will make someone else think it should start from 0. They will change it and break it.

57 minutes ago, Bass wrote

*snip*

Well you are debugging poorly written code. If the code you are reading is hard to understand, that's the code's problem. I stick to what I said: clean code doesn't need (and shouldn't have) comments. Why? Because clean code is ALWAYS understandable in it's own right.

Yes.  All one must do is put oneself into the exact mindset of the original coder and enlightenment will occur.  And all projects are of a size that allows a single developer to keep track of all business logic and esoterica within their own head.  And people always interpret names the same way.  And we all speak english.

Seriously?!?

"And all projects are of a size that allows a single developer to keep track of all business logic and esoterica within their own head. "

If your business logic is written cleanly and correctly you wouldn't have to remember it all.

"And people always interpret names the same way.  And we all speak english."

And how will comments help there? Comments are also often written in the English language and are often misinterpreted as well.

14 hours ago, Bass wrote

@ScanIAm:

"And all projects are of a size that allows a single developer to keep track of all business logic and esoterica within their own head. "

If your business logic is written cleanly and correctly you wouldn't have to remember it all.

Gotcha.  You write clean and correct code so those of us who might have to follow up after you can just suck it.

"And people always interpret names the same way.  And we all speak english."

And how will comments help there? Comments are also often written in the English language and are often misinterpreted as well.

It's called 'context'. 

Expecting the next developer to have to read pages of code just to figure out WTF you where thinking is unethical.  Doing so on a large project is counterproductive.

I know you'll want to continue to argue this, so how about we split the difference.  I won't make you comment if you won't ever work on any code I'll eventually have to fix.

Deal?

17 hours ago, Bass wrote

*snip*

Well you are debugging poorly written code. If the code you are reading is hard to understand, that's the code's problem. I stick to what I said: clean code doesn't need (and shouldn't have) comments. Why? Because clean code is ALWAYS understandable in it's own right.

In that case I have never, ever seen clean code. If what you say is true I don't think human beings are capable of producing clean code.

http://rd3d2.wordpress.com/2011/04/27/the-application-must-not-exceed-90-mb-of-ram-usage/

19 hours ago, Bass wrote

@ScanIAm:

*snip*

If your business logic is written cleanly and correctly you wouldn't have to remember it all.

The geniuses I followed behind said the same thing. And yes I'm sucking it now. Maybe I'm just holding it wrong.

7 hours ago, ScanIAm wrote

Gotcha.  You write clean and correct code so those of us who might have to follow up after you can just suck it.

That is what code reviews are for.

It's called 'context'. 

Expecting the next developer to have to read pages of code just to figure out WTF you where thinking is unethical.  Doing so on a large project is counterproductive.

I know you'll want to continue to argue this, so how about we split the difference.  I won't make you comment if you won't ever work on any code I'll eventually have to fix.

Deal?

This "comments are for crappy code" idea isn't magical crap I make up the other day, it's fairly accepted idea these days in software engineering circles that comments are a crutch for poorly written code.

Here is a quote you can ponder if you like:

“The proper use of comments is to compensate for our failure to express yourself in code. Note that I used the word failure. I meant it. Comments are always failures.” --Robert Martin

4 days ago, JoshRoss wrote

@Charles: When is the last time you had a problem and solved it by writing a program? Did you ever work on any of those Project Euler problems?

-Josh

Yes. In fact, I do write small programs to solve random problems of personal technical interest or to try and find a bug in some code I grab from an internal technical discussion alias to help a colleague out, but this is not really being a programmer (like when I would design and implement programs to solve problems of a much larger scale...). It's more tinkering than programming in my opinion. The last time I did this was today, actually

C

22 hours ago, Bass wrote

 

If your business logic is written cleanly and correctly you wouldn't have to remember it all.

Don't you even put your bussiness deparment's "clearnly written business logic" in your comment? How the hell would I know your mean Business Logic 1.2 or 1.5?

1 minute ago, magicalclick wrote

*snip*

Don't you even put your bussiness deparment's "clearnly written business logic" in your comment? How the hell would I know your mean Business Logic 1.2 or 1.5?

Business logic is written by software engineers, not business people. Business people at most can levy requirements on the software, but it is up to the software engineers to convert these requirements into a clean, understandable design. That it totally the software team's responsibility. If you have business people dictating software design to you, you are already screwed comments or not. Not even unit testing or code reviews will save you.

1 minute ago, exoteric wrote

Common sense: 1) the smaller the syntactic fragment, the less commenting should be necessary, 2) the more declarative the syntactic fragment, the less commenting should be necessary. Large imperative chunks of code is a better target for comments than small composable monadic queries encapsulated in functions. In general expressions are clearer than statements. LINQ queries already read like plain english, that's part of their beauty: they are often self-documenting. There bass is right. For large chunks of imperative monolithic side-effecting code, clearly mortals would appreciate comments. Then there is the distinction between code (re)use vs code change. A piece of code may not require comments to be used but may require "internal comments" to be refactoring-friendly. It's common sense...

I would argue that "large chunks of imperative monolithic side-effecting code" is not clean code.

That is what code reviews are for.

Yes.  As I said, you leave the figuring out for after you've left.

This "comments are for crappy code" idea isn't magical crap I make up the other day, it's fairly accepted idea these days in software engineering circles that comments are a crutch for poorly written code.

Here is a quote you can ponder if you like:

“The proper use of comments is to compensate for our failure to express yourself in code. Note that I used the word failure. I meant it. Comments are always failures.” --Robert Martin

http://blog.mpathirage.com/2010/08/15/comments/

Read the whole thing.  Even he admits it isn't possible.

And while I applaud and encourage the "Agile is Pefection" concept, I'm adult enough to recognize that reality doesn't always work that way.

4 minutes ago, ScanIAm wrote

*snip*

Yes.  As I said, you leave the figuring out for after you've left.

Comments don't magically make crappy code more understandable in my opinion. I've seen plenty of well commented code that I could not get my head around.

And really I stress this because it's important: "comments can lie". You can read a comment that tells you something that is patently wrong. And it's EASY to write comments that lie. IIRC there is no such thing as a unit test for comments. They don't compile either. Just considering that, you should be scared of them. Considering that I consider comments borderline dangerous.

*snip*

http://blog.mpathirage.com/2010/08/15/comments/

Read the whole thing.  Even he admits it isn't possible.

And while I applaud and encourage the "Agile is Pefection" concept, I'm adult enough to recognize that reality doesn't always work that way.

I've read his whole book on clean code. He does believe that sometimes comments are unavoidable, but not because it's okay to write comments in clean code. It's never okay.

Robert Martin understands that nobody is perfect and tools/languages aren't perfectly descriptive either. Sometimes it's beyond the programmers capability to write clean code (ie. code that can not be understood in it's own right), and he must use a comment to explain what he is doing. As a crutch for unclean code.

That's the important thing to remember: comments are ALWAYS a crutch for unclean code. Sometimes you need crutches but you don't need to actively beat yourself to death by littering a code base with them.

A lot of the code I'm wading through these days is very declarative with parts spread out in small, syntactic fragments throughout the finely grained layers of the application (which I might add highly conforms to the concept of "seperation of concerns"). Without comments it takes quite a bit of time to wade through all of the fragments in all of the layers to figure out how the damn thing works -- and that's just small peice of the puzzle. Imagine trying to keep track of hundreds of these undocumented implementation details.

High ideals are great but they fall apart in the real, imperfect world where people actually reside. It's there that the academics fail to everyone but themselves (they of course are too arrogant to notice the pain they have caused others).

-Josh

So you are saying when Business dept tell you the they have new tax laws to follow where specific event triggers a specific tax condition (not just tax rate), and you say no? When business dept say they have to add a stage in their work flow to improve quality of their productivity, you say no?

Anyway, pointless to keep going back and forth. You believe what you like. You probably will not run into the need for comment anway.