- Commenting code considered harmful - 3 Updates
- Unit testing (Re: Putting project code in many different files) - 22 Updates
| Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Feb 03 05:35PM Verbose commenting of code (especially of implementation details) can be dangerous as quite often the code evolves and old comments are not updated in tandem with the code changes and become out of date no longer reflecting what the code actually does. These erroneous comments can have disastrous consequences if incorrect assumptions are made based on them. The best form of documentation is the code itself! /Flibble |
| Gareth Owen <gwowen@gmail.com>: Feb 03 05:44PM > Verbose commenting of code (especially of implementation details) can > be dangerous ... The best form of documentation is the code itself! Bravo! You have excelled yourself. Expect a million bites, and not just on sausages. |
| Christian Gollwitzer <auriocus@gmx.de>: Feb 03 07:08PM +0100 Am 03.02.16 um 18:44 schrieb Gareth Owen: >> be dangerous ... The best form of documentation is the code itself! > Bravo! You have excelled yourself. > Expect a million bites, and not just on sausages. Where it hurts most :P |
| Jerry Stuckle <jstucklex@attglobal.net>: Feb 02 07:54PM -0500 On 2/2/2016 4:33 PM, Gareth Owen wrote: >> But then trolls, when they can't refute facts, have to resort to ad >> hominem attacks. Except it didn't work in this case. > Sick burn, Don. Yup, except your ad hominem attack doesn't work. I don't mind at all being compared to a successful businessman. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ================== |
| Jerry Stuckle <jstucklex@attglobal.net>: Feb 02 07:56PM -0500 On 2/2/2016 3:50 PM, Ian Collins wrote: > There were a couple of novel concepts invented way back in the history > of SCM tools called "tags" and "branches". Read up on them, you'll > learn something. Yes, I know about them. But you've already proven you don't understand proper project management or design, so I'm not going to waste my time trying to explain why they aren't the entire answer. There's an old adage - "Never teach a pig to sing. It wastes your time and annoys the pig.". I'm not going to try to teach the pig to sing. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ================== |
| Jerry Stuckle <jstucklex@attglobal.net>: Feb 02 08:04PM -0500 On 2/2/2016 5:07 PM, Öö Tiib wrote: > We did not talk about test systems/farms/clouds and sizes of those. > I did talk about pushing changes into shared workspace of team, IOW > common repo of team. I wasn't talking about clouds, either. But you're the one who indicated your production repo had test cases and results in it - things which don't belong there. > That does contaminate nothing. What repo does somehow migrate > code or other files between branches or up and down of revisions and > tags and contaminates something? Sure - and you have to look at every single one to understand what's changed and what hasn't. You can't easily back up a clean copy of just the changed files; nor can you easily create a service pack from just the changed files. Even backing out one change can be problematic, especially if there are other changes to one or more files. > repos that I have seen changes done in one branch are sometimes "merge"d > to other branch. Usually there is certain process for that. Files that > are needed for nothing in a branch are simply erased. They can be implemented in hard driver folders - but they are typically repos. However, it's also impossible to compile from repos without downloading the files. And erasing a file from a branch accidentally can be disastrous - especially if there have been changes to that file. You seldom have an easy backup of the repo. >> it was shipped as well as code currently being worked on. > Backups are orthogonal and I am unsure what these have to do with any > of it. Backups are key to any development cycle. The projects I've worked on backup all files daily. It's saved the bacon more than once when someone screwed up the repo accidentally. > they work in separation before they push their changesets or provide > their patches for common repo between teams or organizations but I > have nowhere seen that files are moved between repos like you describe. They have, on every project I've ever worked. You never test on a development repo, and never change what's on a production repo. In the latter case you may replace a file (after testing), but they are never changed. And upload permission to the production repo is tightly controlled. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ================== |
| Jerry Stuckle <jstucklex@attglobal.net>: Feb 02 08:05PM -0500 On 2/2/2016 3:57 PM, Ian Collins wrote: >> which can terminate the test - and finally, evaluate the results. > There is software to do all of the donkey work known as unit test > frameworks. Read up on them and you might learn something. There's an old adage - "Never teach a pig to sing. It wastes your time and annoys the pig.". I'm not going to try to teach the pig to sing. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ================== |
| Ian Collins <ian-news@hotmail.com>: Feb 03 03:18PM +1300 Jerry Stuckle wrote: > Yes, I know about them. But you've already proven you don't understand > proper project management or design, so I'm not going to waste my time > trying to explain why they aren't the entire answer. We all know that you wouldn't be able... > There's an old adage - "Never teach a pig to sing. It wastes your time > and annoys the pig.". I'm not going to try to teach the pig to sing. Jolly good. -- Ian Collins |
| Gareth Owen <gwowen@gmail.com>: Feb 03 07:43AM > Yup, except your ad hominem attack doesn't work. I don't mind at all > being compared to a successful businessman. That you openly admire Donald Trump is a better piece of character assassination than anything I could actually invent. |
| Paavo Helde <myfirstname@osa.pri.ee>: Feb 03 10:04AM +0200 On 3.02.2016 3:04, Jerry Stuckle wrote: > Backups are key to any development cycle. The projects I've worked on > backup all files daily. It's saved the bacon more than once when > someone screwed up the repo accidentally. Now you stepped a bit too far. It is not interesting to argue any more if the opponent plays a troll so obviously. |
| David Brown <david.brown@hesbynett.no>: Feb 03 09:18AM +0100 On 03/02/16 02:04, Jerry Stuckle wrote: > Backups are key to any development cycle. The projects I've worked on > backup all files daily. It's saved the bacon more than once when > someone screwed up the repo accidentally. I don't know what sort of version control system you use, but it sounds medieval - perhaps it was MS "Source Safe" ? First, backups have /nothing/ to do with any development cycle. They are for disaster recovery - you use them when your server goes up in smoke (unless your size and budget allows for clustering or online redundancy, in which case you only need them when your server room goes up in smoke). If your version control system lets anyone screw up the repository, get a better version control system. If your version control system does not let developers easily see old versions of their files, get a better version control system. If your version control system does not support branches, tags, etc., as appropriate to your development structure, get a better version control system. If your version control system does not support keeping control of who has read or write access to which branches, get a better version control system. If your version control system and development process means that developers cannot commit changes until after they have been fully tested by the independent test team, rather than regularly after each individual change to the code - so that you rely on daily backups to recover code - then you have /really/ messed up. |
| Ian Collins <ian-news@hotmail.com>: Feb 03 09:37PM +1300 David Brown wrote: >> someone screwed up the repo accidentally. > I don't know what sort of version control system you use, but it sounds > medieval - perhaps it was MS "Source Safe" ? I get the impression from what he has posted in this thread and his general lack of development process insight that he last coded in the 80s. Or maybe he has just read some rather old books. -- Ian Collins |
| "Öö Tiib" <ootiib@hot.ee>: Feb 03 03:44AM -0800 On Wednesday, 3 February 2016 03:04:57 UTC+2, Jerry Stuckle wrote: > I wasn't talking about clouds, either. But you're the one who indicated > your production repo had test cases and results in it - things which > don't belong there. It is pointless to have test results of unit tests, these just should pass like code should just compile. The changeset behaving otherwise potentially wastes time of everybody and will be therefore immediately alarmed by continuous integration service so that no one does accidentally pull the dirty commit until its sorry ass author has fixed or reverted it. As of your odd structure of repos, no one has seen it anywhere. > the changed files; nor can you easily create a service pack from just > the changed files. Even backing out one change can be problematic, > especially if there are other changes to one or more files. What? I have clone of full repo of medium project that has lasted for 12 years on my SSD. Updating to any branch, tag or revision takes just few seconds and there it is clean situation as it was. Making diff between any two moments in the whole history takes also only few seconds. Cloning a repo does take slightly longer but even that is not a coffee-break. > downloading the files. And erasing a file from a branch accidentally > can be disastrous - especially if there have been changes to that file. > You seldom have an easy backup of the repo. Delete file, commit change. Done. Again few seconds. Backup is also not an issue. > Backups are key to any development cycle. The projects I've worked on > backup all files daily. It's saved the bacon more than once when > someone screwed up the repo accidentally. You just pull it all out of where? Backups are made automatically by hosting environment. Disaster recovery is no way part of normal development cycle since we are typically not under fire of enemy artillery. Restoring a backup happens may be once in two years, does not take long and meanwhile people just continue working on their local repos as they do on case when someone pushed non-compiling code. > latter case you may replace a file (after testing), but they are never > changed. And upload permission to the production repo is tightly > controlled. Is that "production repo" of yours named with .zip file extension? Can't be. Now I firmly trust you are making it all up just to troll out more responses. |
| Gareth Owen <gwowen@gmail.com>: Feb 03 01:45PM > I get the impression from what he has posted in this thread and his > general lack of development process insight that he last coded in the > 80s. At the very least, that's whe he stopped *thinking* and his opinions about best-practice ossified into his own peculiar set of facts. |
| scott@slp53.sl.home (Scott Lurndal): Feb 03 02:31PM >> But then trolls, when they can't refute facts, have to resort to ad >> hominem attacks. Except it didn't work in this case. >Sick burn, Don. Grow up, both of you. Just walk away. |
| Gareth Owen <gwowen@gmail.com>: Feb 03 02:35PM > Grow up, both of you. Just walk away. But I enjoy prodding bloviating windbags! |
| David Brown <david.brown@hesbynett.no>: Feb 03 04:23PM +0100 On 03/02/16 15:35, Gareth Owen wrote: > scott@slp53.sl.home (Scott Lurndal) writes: >> Grow up, both of you. Just walk away. > But I enjoy prodding bloviating windbags! That is perhaps okay up to a point - and fully understandable in this case. But it quickly gets pointless, and c.l.c. has already had a couple of threads dominated by Jerry and another nitwit repeatedly calling each other trolls. Your Donald Trump reference /was/ witty, IMHO, but now is the time to leave his posts unanswered (unless you are supplying useful technical information for the rest of us, of course). |
| Jerry Stuckle <jstucklex@attglobal.net>: Feb 03 10:41AM -0500 On 2/3/2016 2:43 AM, Gareth Owen wrote: >> being compared to a successful businessman. > That you openly admire Donald Trump is a better piece of character > assassination than anything I could actually invent. That you think a successful businessman is bad is a better piece of character assassination than anything anyone with brains could invent. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ================== |
| Jerry Stuckle <jstucklex@attglobal.net>: Feb 03 10:42AM -0500 On 2/3/2016 3:04 AM, Paavo Helde wrote: >> someone screwed up the repo accidentally. > Now you stepped a bit too far. It is not interesting to argue any more > if the opponent plays a troll so obviously. What's "stepped too far"? Saying backups are key to any development cycle? -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ================== |
| Jerry Stuckle <jstucklex@attglobal.net>: Feb 03 10:50AM -0500 On 2/3/2016 3:18 AM, David Brown wrote: >> someone screwed up the repo accidentally. > I don't know what sort of version control system you use, but it sounds > medieval - perhaps it was MS "Source Safe" ? Nope, I've used several over the years, with different clients. I use whatever they use. > smoke (unless your size and budget allows for clustering or online > redundancy, in which case you only need them when your server room goes > up in smoke). And protecting your data against a disaster is a part of the development cycle. What happens, for instance, if you get a disk crash? Or if a disgruntled employee wipes the entire server (as has happened in at least one instance I know of)? Lots of things can happen. Backing up should be an automated process and is generally done after hours. If you back up nightly, you lose at most one days work. > If your version control system lets anyone screw up the repository, get > a better version control system. See above. Anything can happen at any time. > If your version control system does not let developers easily see old > versions of their files, get a better version control system. Who said they couldn't see old versions of their files? But what about when they change something - and a dozen other people change that file later - and some of those fixes hit the same code the original programmer changed? How are you going to easily back out all of those fixes - especially when each one can affect multiple files. You suddenly have a snowball effect. > If your version control system does not support branches, tags, etc., as > appropriate to your development structure, get a better version control > system. Blah, blah, blah. > If your version control system does not support keeping control of who > has read or write access to which branches, get a better version control > system. Blah, blah, blah. > by the independent test team, rather than regularly after each > individual change to the code - so that you rely on daily backups to > recover code - then you have /really/ messed up. You have absolutely no idea what I'm trying to discuss. I never said any of the above was not possible. But then you've obviously not worked on a project with dozens of programmers. In fact, from your comments, I highly suspect you've never worked on a project with even two programmers. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ================== |
| Jerry Stuckle <jstucklex@attglobal.net>: Feb 03 10:51AM -0500 On 2/3/2016 3:37 AM, Ian Collins wrote: > I get the impression from what he has posted in this thread and his > general lack of development process insight that he last coded in the > 80s. Or maybe he has just read some rather old books. I just finished a project with over 30 programmers last October. It was quite successful, coming in under budget and before the deadline. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ================== |
| Jerry Stuckle <jstucklex@attglobal.net>: Feb 03 11:08AM -0500 On 2/3/2016 6:44 AM, Öö Tiib wrote: > continuous integration service so that no one does accidentally pull the > dirty commit until its sorry ass author has fixed or reverted it. As of your > odd structure of repos, no one has seen it anywhere. It is *critical* to have test results of unit tests. They will be needed for regression testing when code changes are made. And the tests need to include "bad" results such as rejection of invalid input data such as a future date for a birth date. But these tests should not be on the production repo. > and there it is clean situation as it was. Making diff between any two moments > in the whole history takes also only few seconds. Cloning a repo does take > slightly longer but even that is not a coffee-break. Now how do you keep someone from using untested code (or code which has failed tests) when making other changes? Or how do you even ensure the code has successfully passed tests? And diff only works well if you distribute source files. Most projects I work on the source files are not distributed. >> You seldom have an easy backup of the repo. > Delete file, commit change. Done. Again few seconds. Backup is also not > an issue. You didn't answer my question. What happens if you delete a file from the repo? You no longer have that file since you don't have a backup. > not take long and meanwhile people just continue working on their > local repos as they do on case when someone pushed non-compiling > code. Yes, but they still are critical. Disaster recovery does not necessarily mean server failure. It means you lost something that you need. It could even be erasing a critical file - or even deleting a file accidentally from the repo. As to local repos - now what do you do when you have five people making five different (and incompatible) changes to a file? And if you lose a file on the main repo, local repo do you use to restore it? > Is that "production repo" of yours named with .zip file extension? Can't > be. Now I firmly trust you are making it all up just to troll out more > responses. Who said anything about a .zip file? These are repos. Period. But write access to the production repo is tightly controlled. Only tested code is allowed on it, and only the lead people in the test group have permission to write to it. It's pretty obvious you've never been involved in a formal project management scenario. Your method may be ok for two or three programmers, but would never work when you have > 100 developers working on a project at the same time. You need specific processes in place, and those processes must be followed. Otherwise the result can be chaos. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ================== |
| Paavo Helde <myfirstname@osa.pri.ee>: Feb 03 06:58PM +0200 On 3.02.2016 18:08, Jerry Stuckle wrote: > You didn't answer my question. What happens if you delete a file from > the repo? Revert the last commit? > Who said anything about a .zip file? These are repos. svn or git? |
| Gareth Owen <gwowen@gmail.com>: Feb 03 05:54PM > That you think a successful businessman is bad is a better piece of > character assassination than anything anyone with brains could invent. A massively racist demagogue, who is also a successful business. I'm fine with my choices. |
| scott@slp53.sl.home (Scott Lurndal): Feb 03 06:07PM >Revert the last commit? >> Who said anything about a .zip file? These are repos. >svn or git? or cvs or rcs or sccs or clearcase or bitkeeper or perforce? |
| You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page. To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com. |
No comments:
Post a Comment