Singletrack Mountain Bike Magazine

• Overview
• Bike Forum
• Chat Forum
• For Sale
• Wanted
• Forum Help
• Classified Rules

Chat Forum

1. molgrips - Member

   Code reviews have much less relevance nowadays as it is more difficult to grock what the code is doing from just reading it

   I would disagree in my area of enterprise application development. Mostly you are just tying APIs together, and the code itself is very noddy.

   As for buddy programming - two developers often work more than twice as fast as one, ime. No time for daydreaming, surfing STW or general slacking.

   Turner guy seems to be talking about large systems undergoing continuous development and maintenance within an organisation. Like I keep saying, these approaches are all tools you can deploy if appropriate.

   Posted 1 year ago #
2. TurnerGuy - Member

   I have also used TDD style for smaller projects and love the feeeling of solidity you get from it - the time taken writing the tests is easily compensated for by the lack of the traditional debugging.

   Before using that style I would like to walk through new code in the debugger, as recommended in "writing solid code", but find the need less now. And when using 'technologies' like xslt using TDD style tests to prove the logic you want is invaluable, as it often doesn't work as you think it should from looking at the code.

   With mickey mouse languages like Java and C# I feel TDD is essential, but have used it with C++ to good effect.

   Async stuff is a problem still, but it is better than nothing.

   Posted 1 year ago #
3. GrahamS - Member

   The tests are to test logic, testing getters and settings is pedantic.

   Yes, yes it is. Aren't tests supposed to be pedantic??
   I don't test to prove that it is more or less basically right, give or take.

   Likewise I use a compiler set to -pedantic, I am pedantic about fixing warnings and I use pedantic tools like lint, StyleCop, BullsEye, etc.

   Code reviews have much less relevance nowadays as it is more difficult to grock what the code is doing from just reading it. Peer reviews were one developer explains the code and functionality to another are much more useful.

   The trouble with peer-reviews is that it is like someone reading you an essay they wrote, rather than reading it yourself. It is easier to understand their intent, but much harder to spot basic errors.

   If the code is hard to grock then it is poorly written and documented. A future maintenance programmer may not have the luxury of the original author on hand to explain it - so it should be understandable without him/her.

   Posted 1 year ago #
4. molgrips - Member

   Exactly.

   I like to write code that's so obvious it doesn't need documentation apart from on a high level.

   Posted 1 year ago #
5. mogrim - Member

   grock

   ?

   Grok, surely. And if you fail at that level of basic geekdom, I don't want you anywhere near my code!

   And don't talk to me about coding standards that make you javadoc every single method, member, ...

   Posted 1 year ago #
6. j_me - Member

   code that's so obvious it doesn't need documentation apart from on a high level

   So its undocumented as well as untested....
   .....oh the horror, the HORROR !

   Posted 1 year ago #
7. molgrips - Member

   So its undocumented as well as untested....

   But working perfectly, delivered before the deadline and under budget to a very happy client.. How is such sorcery possible?!

   Posted 1 year ago #
8. TurnerGuy - Member

   Grok, surely

   that was a trap to catch the true geeks who would correct the spelling error...

   Posted 1 year ago #
9. TurnerGuy - Member

   The trouble with peer-reviews is that it is like someone reading you an essay they wrote, rather than reading it yourself. It is easier to understand their intent, but much harder to spot basic errors.

   Whereas just reading code used to be useful in the days of simpler coding styles/languages, nowadays it can be less easy to see the full intent of the code by just looking at it, with active objects, event handling, etc.

   Therefore having the author explaining the code and intent of the system to the reviewer(s), possibly at her terminal tends to offer high value as well as low overhead and is worth doing. Old style code-reading is rarely worthwhile.

   Posted 1 year ago #
10. molgrips - Member

    I'm not a geek, that's why I'm good at my job

    Posted 1 year ago #
11. GrahamS - Member

    it can be less easy to see the full intent of the code by just looking at it, with active objects, event handling, etc.

    Possibly but you should still be able to make sense of a single class/component without knowing the full context of the system. If you can't then that suggests it is poorly designed, doesn't follow SOLID principles and will be a maintenance headache later in the life-cycle.

    I've code reviewed everything from ARM assembler and bit-bashed I2C drivers in C, up to enterprise applications in Java, C++ and C#. If someone needs to take my hand to lead me through it then it is crap code.

    Posted 1 year ago #
12. DaRC_L - Member

    welcome to the world of off-shoring where variables and comments come in a variety (usually jumbled together) of languages.

    Posted 1 year ago #
13. TurnerGuy - Member

    I'm not a geek, that's why I'm good at my job

    You must be a geek otherwise you would not recognise the word and I must be less of a geek as, although I recognised the word, I could not spell it correctly

    Posted 1 year ago #
14. TurnerGuy - Member

    If someone needs to take my hand to lead me through it then it is crap code.

    they are not leading you through the code that is in front of you, they are responding to questions about how the system works. You could sit there looking for all references to that object/method and work it all out, but having a more interactive session is more time efficient. With everyone under time pressure nobody wants to sit there for hours pondering over some code listings, and they won't. And there is little point human readers repeating what an automatic tool or compiler setting could achieve.

    Anyway, with TDD styles the important thing is public interfaces, not necessarily the underlying code which may be put together in less than ideal conditions to met the next deadline, and will be refactored afterwards. The tests prove that, although the code is sub-optimal, it meets it goals - and that is what you want after all.

    Posted 1 year ago #

RSS feed for this topic

Topic Closed

This topic has been closed to new replies.