Dang ! So I think 'Hmmm, I just need to check a detail or two', so I track down the book... that was 4 hours ago. I hate it when that happens:)!
There are so many ways they could gruesomely mangle such a delicate story it's scary. This could make Lynch's Dune look like a sensitive interpretation.
Perhaps we should put our faith in child abuse. We need a 'Friends of Ender' organisation to suggest to Hollywood ( well, anyone who'll listen... ) that Ender's Game glorifies abusive relationships with children, seeks to justify the use of children as soldiers ( I'm sure there's a UN Treaty or something about that ), encourages children who use the net to deceive others about their age, and is actually little more than a twisted shadow of Lord of the Flies.
Now done as dark Manga, that might be a different picture...
But I are the communication skills needed by software engineers the same as those required by computer scientists ?
The communication infrastructure in most corporations still seems to be very hierarchical - diplomacy and a suitable amount of arse licking/covering are prerequisites for actually being able to influence what happens at any level, including the technical.
I've heard that academic environments are just as political as business ones, but I still have the impression that *teamwork* ( and the attendant communication ) is not as important a skill in academia as in business.
Hmmm. I've encountered two schools of thought regarding the 'every line is accounted for by descriptive sentences' thing.
The first is yours - you like to *read* a piece of code ( including comment.. ) and, as far as is possible, be completely informed as to it's purpose. I must admit, as a reviewer I also appreciate 'self contained' code - code that doesn't require me to chase around a zillion files/documents in order to understand *why* 'flubberdigit13 ^= DDIC_1473' is a good thing to be doing at this point.
But there's also a 'level of abstraction' decision to be made here. To what extent/at what level should 'design' be captured by comments embedded in the source ? I think that a feature of approaches such as yours is that it encourages the inclusion of 'higher level' design information into source.
Hence the other school of thought - comments should clarify the narrow-focus details of particular coding constructs, but should deliberately avoid re-explaining design details which are captured in some 'out of band' fashion. At most, a design cross reference may be justified.
This has maintainance benefits - changes to the design/architecture are no longer so tightly coupled to the actual source code itself, and the sheer volume of text to be maintained is reduced. It also allows design to be captured in the most appropriate form ( which is not always purely textual ), without forcing a coder to make a clumsy and inaccurate ad hoc mapping into a textual format just for the purpose of creating a comment.
So I guess I'm just saying be careful about requiring voluminous explanations in source code - 'nice to review' is not always the same as 'nice to maintain'.
I kind-of agree with the multiple-pass idea, but from a different POV.
There are two important 'comment passes'. The first is when the code first gets written. At this point you should be able to say what it is the code should do, because you're working from some sort of spec., even if it's been written on the tip of one of Cowboy Neal's spurs.
Now, the critical point is that you revisit the comments *after you've got it working*. Only *now* can you write what the code is actually doing and justify how it's doing it. Plus, the seperation in time between initial code creation and this comment review gives you a little of the feeling of someone coming to your code cold - nobody is better placed to comment those 'WTF' code moments than the author, i.e. you.
I'm not saying don't write any comments to start with - I usually base my initial code drafts around a roughed-out design written as comment - but it's only when you come back to it as described above that the comment process can be completed.
Slashdot Mirror
Dang ! So I think 'Hmmm, I just need to check a detail or two', so I track down the book... that was 4 hours ago. I hate it when that happens :)!
There are so many ways they could gruesomely mangle such a delicate story it's scary. This could make Lynch's Dune look like a sensitive interpretation.
Perhaps we should put our faith in child abuse. We need a 'Friends of Ender' organisation to suggest to Hollywood ( well, anyone who'll listen... ) that Ender's Game glorifies abusive relationships with children, seeks to justify the use of children as soldiers ( I'm sure there's a UN Treaty or something about that ), encourages children who use the net to deceive others about their age, and is actually little more than a twisted shadow of Lord of the Flies.
Now done as dark Manga, that might be a different picture...
>Some observers have expressed concerns over the fact that most, if not all of them are already
>copywritten by the RIAA.
Just wait 'til Wolfram finds a cellular automaton ruleset that generates the RIAA, then we'll see who's got copyright on who....
But I are the communication skills needed by software engineers the same as those required by computer scientists ?
The communication infrastructure in most corporations still seems to be very hierarchical - diplomacy and a suitable amount of arse licking/covering are prerequisites for actually being able to influence what happens at any level, including the technical.
I've heard that academic environments are just as political as business ones, but I still have the impression that *teamwork* ( and the attendant communication ) is not as important a skill in academia as in business.
Hmmm. I've encountered two schools of thought regarding the 'every line is accounted for by descriptive sentences' thing.
The first is yours - you like to *read* a piece of code ( including comment.. ) and, as far as is possible, be completely informed as to it's purpose. I must admit, as a reviewer I also appreciate 'self contained' code - code that doesn't require me to chase around a zillion files/documents in order to understand *why* 'flubberdigit13 ^= DDIC_1473' is a good thing to be doing at this point.
But there's also a 'level of abstraction' decision to be made here. To what extent/at what level should 'design' be captured by comments embedded in the source ? I think that a feature of approaches such as yours is that it encourages the inclusion of 'higher level' design information into source.
Hence the other school of thought - comments should clarify the narrow-focus details of particular coding constructs, but should deliberately avoid re-explaining design details which are captured in some 'out of band' fashion. At most, a design cross reference may be justified.
This has maintainance benefits - changes to the design/architecture are no longer so tightly coupled to the actual source code itself, and the sheer volume of text to be maintained is reduced. It also allows design to be captured in the most appropriate form ( which is not always purely textual ), without forcing a coder to make a clumsy and inaccurate ad hoc mapping into a textual format just for the purpose of creating a comment.
So I guess I'm just saying be careful about requiring voluminous explanations in source code - 'nice to review' is not always the same as 'nice to maintain'.
I kind-of agree with the multiple-pass idea, but from a different POV.
There are two important 'comment passes'. The first is when the code first gets written. At this point you should be able to say what it is the code should do, because you're working from some sort of spec., even if it's been written on the tip of one of Cowboy Neal's spurs.
Now, the critical point is that you revisit the comments *after you've got it working*. Only *now* can you write what the code is actually doing and justify how it's doing it. Plus, the seperation in time between initial code creation and this comment review gives you a little of the feeling of someone coming to your code cold - nobody is better placed to comment those 'WTF' code moments than the author, i.e. you.
I'm not saying don't write any comments to start with - I usually base my initial code drafts around a roughed-out design written as comment - but it's only when you come back to it as described above that the comment process can be completed.