|
From: Anton A. <ai...@ca...> - 2003-02-26 12:32:15
|
On Fri, 21 Feb 2003, Szakacsits Szabolcs wrote: > My experience is that you occasionally make a wrong fix (I told, > nobody is perfect) and making things worse sometimes you even don't > communicate the broken fix back for confirmation I reported before > making and announcing the new release/snapshots. I also noticed, you > don't always test/verify your code. Don't think I mean you have to. Oh, I have made a wrong fix? Is it properly fixed now or still broken? Can you point me to what you mean? I don't test/verify code. I often don't even compile test when I commit to bitkeeper. I rely on my thought processes to verify the correctness of the code. Admittedly that sometimes goes horribly wrong. I only test when something big enough has been completed or before making a big release. For example when the code was ready to be able to resize a resident file, I tested that, and later when I had cluster freeing implemented and shrinking of non-resident files I tested the two things simultaneously. Now I have conversion to non-resident attributes implemented I tested that and it seems to all work fine. I just need to verify the cluster allocator is actually doing sane things before I am totally happy with it as I haven't looked at whether it allocated actually free clusters and whether it wrote to the $Bitmap system file correctly but I just assumed it did for the moment... > The quality and coding style of the ntfs library is also error-prone. > Ultra-long functions, copy-pastes all over, confusing/misnomer naming, > inconsistent API, etc. Long functions: I like long functions and have never agreed with people who think that no function should be longer than a screenfull of lines. It makes the code well slower to have short functions (unless you inline everything) because of the subroutine entry/exit and local function stack setup and on stack parameter passing. It seems extremely stupid to me to code that way... Especially as I find that having to jump around a source code file in order to find what each of the functions does is time consuming. Much better if I can just read from top down and find what the code does in one go. And I certainly can't see why that is supposed to be more error prone than short functions. I personally find exactly the opposite to be the case. Copy-paste: Yes, that happens a lot. Just normal program evolution. (-: Usually when I accumulate a few identical copies of a piece of code I break it out into its own function during one of my spring clean up sessions which admittedly could take place a bit more frequently... Confusing/misnomer naming: Where? I don't find anything confusing (well there are probably a few that are confusing but misnomer???). Also I thought we were all happy now after all the big renames happened. Inconsistent API: Where? I thought it was consistent now after the last rewrite and big renames... > > The version of the development tree will be "ntfsprogs 1.x+1.y-devel" > > for a stable version of "ntfsprogs 1.x.y". > > That looks ok, if you mean 1.8.0-devel (your notation implies 1.8.1). Er, yes, sorry, sould have used a "z" instead of a "y" in one of them. > Thanks for explaining. I hope I wasn't offending, it wasn't my > intention. No don't worry. (-: Ok, now there is a new repository ntfsprogs-devel and it sports the version number 1.8.0-devel. Happy? (-: Best regards, Anton -- Anton Altaparmakov <aia21 at cantab.net> (replace at with @) Linux NTFS maintainer / IRC: #ntfs on irc.freenode.net WWW: http://linux-ntfs.sf.net/ & http://www-stu.christs.cam.ac.uk/~aia21/ |
