Coffeehouse Thread

73 posts

The hardest part about programming is...

Back to Forum: Coffeehouse
  • User profile image
    Bass

    @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.

    "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.

  • User profile image
    ScanIAm

    , 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?

  • User profile image
    Sven Groot

    , 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.

  • User profile image
    MasterPi

    P != NP

    Crying

  • User profile image
    Ian2

    Dealing with things that are outside your immediate control

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

  • User profile image
    DeathBy​VisualStudio

    , 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.

     

  • User profile image
    Bass

    , 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

  • User profile image
    Charles

    , 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 Smiley

    C

  • User profile image
    magicalclick

    , 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?

    Leaving WM on 5/2018 if no apps, no dedicated billboards where I drive, no Store name.
    Last modified
  • User profile image
    Bass

    , 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. Smiley

  • User profile image
    exoteric

    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...

  • User profile image
    Bass

    , 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. Smiley

  • User profile image
    ScanIAm

    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.

  • User profile image
    exoteric

    @bass it might be efficient and pragmatic tho...

  • User profile image
    Bass

    , 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.

  • User profile image
    DeathBy​VisualStudio

    One problem that is being ignored by Bass and the like is that "clean code" is subjective. We aren't machines. We don't all start from the same point no matter how clear the spec is. 

    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).

    If we all believed in unicorns and fairies the world would be a better place.
    Last modified
  • User profile image
    Bass

    Hmm I seem to be sensing something quite passive agressive. Smiley

  • User profile image
    JoshRoss

    I would like to offer a solution. Write your comments before you write the code, write more comments than code. Then change the color of the comment text to match the background color, so you don't have to see your or other people's crappy comments.

    -Josh

Comments closed

Comments have been closed since this content was published more than 30 days ago, but if you'd like to continue the conversation, please create a new thread in our Forums, or Contact Us and let us know.