* ada writing guide @ 2000-04-12 0:00 Riyaz Mansoor 2000-04-12 0:00 ` Ted Dennison ` (2 more replies) 0 siblings, 3 replies; 76+ messages in thread From: Riyaz Mansoor @ 2000-04-12 0:00 UTC (permalink / raw) i was wondering where i can get/find ada code conventions? i know C has a standard. like for example what is the "standard" way to write a procedure declaration. procedure (D : in out Data; C : in Cata); procedure (D : in out Data; C : in Cata); or what? thanx riyaz ******************* ^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: ada writing guide 2000-04-12 0:00 ada writing guide Riyaz Mansoor @ 2000-04-12 0:00 ` Ted Dennison 2000-04-12 0:00 ` Robert Dewar 2000-04-13 0:00 ` Riyaz Mansoor 2000-04-12 0:00 ` Robert Dewar 2000-04-14 0:00 ` Riyaz Mansoor 2 siblings, 2 replies; 76+ messages in thread From: Ted Dennison @ 2000-04-12 0:00 UTC (permalink / raw) In article <8d1rso$bir$2@bunyip.cc.uq.edu.au>, "Riyaz Mansoor" <s800032@student.uq.edu.au> wrote: > > i was wondering where i can get/find ada code conventions? i know C > has a standard. Try the Ada Quality and Style Guide, at http://wuarchive.wustl.edu/languages/ada/ajpo/docs/style-guide/95style/h tml/cover.html It is mean to be tailored to match site-specific guidlines, but it still should give you a good idea of what is typical usage. > like for example what is the "standard" way to write a procedure > declaration. > > procedure (D : in out Data; C : in Cata); > procedure > (D : in out Data; > C : in Cata); You forgot the procedure's name. ;-) I prefer: procedure Foo (D : in out Data; C : in Data ); but some prefer procedure Foo (D : in out Data; C : in Data); I prefer the former because the parameters start in a standard place, and won't get squeezed for space if the procedure name is long. Also, its easier to see that the parens match. It does use up more vertical real-estate, though (in this case, twice as much). -- T.E.D. http://www.telepath.com/~dennison/Ted/TED.html Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: ada writing guide 2000-04-12 0:00 ` Ted Dennison @ 2000-04-12 0:00 ` Robert Dewar 2000-04-13 0:00 ` Jeffrey D. Cherry 2000-04-13 0:00 ` Ted Dennison 2000-04-13 0:00 ` Riyaz Mansoor 1 sibling, 2 replies; 76+ messages in thread From: Robert Dewar @ 2000-04-12 0:00 UTC (permalink / raw) In article <8d1vhj$hdr$1@nnrp1.deja.com>, Ted Dennison <dennison@telepath.com> wrote: > You forgot the procedure's name. ;-) I prefer: > procedure Foo > (D : in out Data; > C : in Data > ); I find the use of IN redundant since it is the default, but this is a matter of taste, as usual the critical thing is to be consistent. I especially find the use of IN annoying in functions. I find the extra ); on its own line offensive and unnatural, just as clear, and much easier on the eye to write > procedure Foo > (D : in out Data; > C : in Data); In GNAT we prefer to put things on a single line: > procedure Foo (D : in out Data; C : Data); If they fit comfortably on one line, and use the form with one line per parameter only if that is not the case. Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: ada writing guide 2000-04-12 0:00 ` Robert Dewar @ 2000-04-13 0:00 ` Jeffrey D. Cherry 2000-04-13 0:00 ` Ted Dennison ` (2 more replies) 2000-04-13 0:00 ` Ted Dennison 1 sibling, 3 replies; 76+ messages in thread From: Jeffrey D. Cherry @ 2000-04-13 0:00 UTC (permalink / raw) Robert Dewar wrote: > > I find the extra ); on its own line offensive and unnatural, > just as clear, and much easier on the eye to write > > > procedure Foo > > (D : in out Data; > > C : in Data); > > In GNAT we prefer to put things on a single line: > > > procedure Foo (D : in out Data; C : Data); > > If they fit comfortably on one line, and use the form with > one line per parameter only if that is not the case. I quite agree that if a complete declaration can appear on one line, it should not be arbitrarily broken up into two or more lines. I also agree with the ");" looking silly when it's on a line by itself. The part about "in" mode for parameters (not quoted above, but in the original post) I would also agree with, especially with function parameters. Now here is where I stray ... just a bit. I like the following form for a subprogram declaration: procedure Foo( D : in out Data; C : in Data); There are two subtle differences. First, I like to put the opening parenthesis on the line with the subprogram name. This allows the parameter names to line up starting in the same column. Second, I don't leave a space between the subprogram name and the opening parenthesis. I'm pretty comfortable with the first point while the second I find is debatable. Personally, I eliminate the space between a subprogram name and its opening parenthesis because it handles parentheses consistently when they are associated with an identifier. However, this might _not_ be the more readable practice. Consider the following contrived example: procedure Silly is function foobar(a : float) return integer is begin -- foobar return integer(float'truncation(a)); end foobar; f : float := 3.33; i : integer; n : array(1..5) of integer := (5, 6, 7, 8, 9); begin -- Silly i := foobar(f) + n(2); end Silly; Notice the consistency in the assignment statement. But is it more readable to write: i := foobar (f) + n(2); This may give the reader a subtle indication that foobar is a function call while n is an array. I am curious to hear what others think of this practice ... is it just silly to worry about or does it indeed improve the readability of an expression? -- Regards, Jeffrey D. Cherry Senior IV&V Analyst Logicon Space and Information Operations Logicon Inc. a Northrop Grumman company ^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: ada writing guide 2000-04-13 0:00 ` Jeffrey D. Cherry @ 2000-04-13 0:00 ` Ted Dennison 2000-04-13 0:00 ` Jeffrey D. Cherry ` (2 more replies) 2000-04-13 0:00 ` Samuel T. Harris 2000-04-13 0:00 ` Paul Graham 2 siblings, 3 replies; 76+ messages in thread From: Ted Dennison @ 2000-04-13 0:00 UTC (permalink / raw) In article <38F5DF8C.1A01E5A4@utech.net>, "Jeffrey D. Cherry" <jdcherry@utech.net> wrote: > Robert Dewar wrote: > > > > I find the extra ); on its own line offensive and unnatural, > lines. I also agree with the ");" looking silly when it's > I like the following form for a subprogram declaration: > > procedure Foo( > D : in out Data; > C : in Data); > I don't mind this so much. But there is a small problem with it. Emacs Ada mode (at least my version of it), will try to line up the parameters with the open paren, so unless you want to fight Emacs your whole life to put it back, you end up with: procedure Foo( D : in out Data; C : in Data); Which is really a smidge worse than: procedure Foo (D : in out Data; C : in Data); ...which is what I was trying to get away from, due to the wasted horizontal space. > Notice the consistency in the assignment statement. But is > it more readable to write: > > i := foobar (f) + n(2); > > This may give the reader a subtle indication that foobar is > a function call while n is an array. I am curious to hear > what others think of this practice ... is it just silly to > worry about or does it indeed improve the readability of > an expression? Interesting. I never really thought about my tendancies here before. I'm one of those who *likes* the syntactic transparency between arrays and functions (and I'm a working engineer who has to debug a lot of other people's bad buggy code, not some "ivory tower acedemic", as had been claimed). Hmmm. It looks like what I do is the following: Most functions have multiple parameters. In this case, named notation is used in a style similar to the one used for subprogram specs. For the rest of the cases, about %90 of the time, there is a single space between the "(" and the identifier. This is true whether its an array, type conversion, or function call. So I do preserve reference transparency. So what's different about the other %10? Some are situations where there is some calculation or complex subranging inside the parenthesis. One theory for why I did this would be that I have been semi-subconciously using extra whitespace to draw the eye to the "important parts" of a line. Other occurances happen when the contents of the parenthesis are another identifier-parenthesis pair. Again, it could be argued that this keeps from drawing undue attention to the identifier on the outside of the operation. However, I suppose it could also be argued that this is just a panicked attempt to save enough space to fit it all on a line, turned into idiom. -- T.E.D. http://www.telepath.com/~dennison/Ted/TED.html Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: ada writing guide 2000-04-13 0:00 ` Ted Dennison @ 2000-04-13 0:00 ` Jeffrey D. Cherry 2000-04-13 0:00 ` Ted Dennison ` (2 more replies) 2000-04-13 0:00 ` Ray Blaak 2000-04-15 0:00 ` Robert Dewar 2 siblings, 3 replies; 76+ messages in thread From: Jeffrey D. Cherry @ 2000-04-13 0:00 UTC (permalink / raw) Ted Dennison wrote: > > procedure Foo( > > D : in out Data; > > C : in Data); > > I don't mind this so much. But there is a small problem with it. Emacs > Ada mode (at least my version of it), will try to line up the parameters > with the open paren, so unless you want to fight Emacs your whole life > to put it back, you end up with: > > procedure Foo( > D : in out Data; > C : in Data); > > Which is really a smidge worse than: > procedure Foo (D : in out Data; > C : in Data); > > ...which is what I was trying to get away from, due to the wasted > horizontal space. Oh I definitely agree with you here. I like neither of the above two forms. Since the indentation is based on the length of an identifier name, differing identifiers produce differing indentation. I think this practice produces an ugly jumble of code that is much more difficult to read when compared to a consistent indentation. Regarding Emacs ... I don't use Emacs so this behavior was a surprise for me. I would guess that there must be a way to change this behavior within Emacs. I don't often use the automated layout features of my editor since my fingers already do their own automated layout. ;) > Hmmm. It looks like what I do is the following: > Most functions have multiple parameters. In this case, named notation > is used in a style similar to the one used for subprogram specs. Would you agree that always using named notation makes the code longer and less readable? Or would you disagree? Is there some optimal number of parameters to a subprogram that makes you use named notation rather than positional notation? Or is there other criteria that makes you choose one method over the other? > For the rest of the cases, about %90 of the time, there is a single > space between the "(" and the identifier. This is true whether its an > array, type conversion, or function call. So I do preserve > reference transparency. Cool. How about another question that is related to array references versus subprogram calls? I've noticed that some people put space between consecutive parameters in a subprogram call, but never put a space between index components in an array reference. For example: Target(i,j) := foobar (a, b, c); In this example, Target is a two dimensional array and foobar is a function that takes three parameters. Should there be a space in the index expression of the array component? Your thoughts? -- Regards, Jeffrey D. Cherry Senior IV&V Analyst Logicon Space and Information Operations Logicon Inc. a Northrop Grumman company ^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: ada writing guide 2000-04-13 0:00 ` Jeffrey D. Cherry @ 2000-04-13 0:00 ` Ted Dennison 2000-04-14 0:00 ` Pascal Obry 2000-04-13 0:00 ` Robert A Duff 2000-04-16 0:00 ` Simon Wright 2 siblings, 1 reply; 76+ messages in thread From: Ted Dennison @ 2000-04-13 0:00 UTC (permalink / raw) In article <38F603FE.B0C3ED83@utech.net>, "Jeffrey D. Cherry" <jdcherry@utech.net> wrote: > Ted Dennison wrote: > Regarding Emacs ... I don't use Emacs so this behavior was a surprise I guess there are still a few of you. :-) I can definitely understand wanting to keep your own council on formatting. But Emacs' is so close to "right" for me, that its really easier just to use it. My main complaint is that occasionaly I don't want the standard capitalization (eg: acronyms). > Would you agree that always using named notation makes the code longer > and less readable? Or would you disagree? Is there some optimal > number of parameters to a subprogram that makes you use named notation > rather than positional notation? Or is there other criteria that I draw the line at one. For single parameter subprograms, (or multiple parameter subprgrams where all but one are left defaulted) there is no possibility of confusion, so it is indeed clearer to not supply the parameter names. The only other situation where I'd advocate leaving off the names is when the parameters are commutative. It might look a little prettier when you write it to just slam all the parameters together with no names. But when the code isn't working, the first thing a person debugging it is going to be forced to do is go back to the spec to verfy that those unnamed parameters weren't confused. > subprogram calls? I've noticed that some people put space between > consecutive parameters in a subprogram call, but never put a space > between index components in an array reference. For example: > > Target(i,j) := foobar (a, b, c); > > In this example, Target is a two dimensional array and foobar is a > function that takes three parameters. Should there be a space in the > index expression of the array component? Your thoughts? On the theory that speaking from practice is better than just blathering about theory, I went to look to see what I've done in the past. What I found is...I don't do that. I do this instead: Target(i)(j) := foobar (a, b, c); In the highly unlikely event that the three parameters of foobar are commutative. More likely something like: Target(i)(j) := foobar (foo => a, bar => b, foobrand => c ); I think "foobrand" is the correct technical term for a parameter to a "foo" function. :-) The problem with multidimensional arrays is that you can't easily take a vector out of them and pass that to a standard subprogram, like you can with arrays of arrays. I almost always end up wanting to do that. Thus I don't use multidimensional arrays. -- T.E.D. http://www.telepath.com/~dennison/Ted/TED.html Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: ada writing guide 2000-04-13 0:00 ` Ted Dennison @ 2000-04-14 0:00 ` Pascal Obry 2000-04-14 0:00 ` Ted Dennison 0 siblings, 1 reply; 76+ messages in thread From: Pascal Obry @ 2000-04-14 0:00 UTC (permalink / raw) [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain, Size: 1690 bytes --] Ted Dennison <dennison@telepath.com> a �crit dans le message : 8d5dsc$c27$1@nnrp1.deja.com... > In article <38F603FE.B0C3ED83@utech.net>, > "Jeffrey D. Cherry" <jdcherry@utech.net> wrote: > > Ted Dennison wrote: > > > Regarding Emacs ... I don't use Emacs so this behavior was a surprise > > I guess there are still a few of you. :-) > > I can definitely understand wanting to keep your own council on > formatting. But Emacs' is so close to "right" for me, that its really > easier just to use it. My main complaint is that occasionaly I don't > want the standard capitalization (eg: acronyms). > This is addressed in latest GLIDE release where you can build an exception list. This way you can write tbd and EMACS will automagically capitalize it to TBD ! You just write it the way you want once and you put it (with a magic key :) in your exception file that's all. So your main complaint is fixed :) Pascal. -- --|------------------------------------------------------------ --| Pascal Obry Team-Ada Member | --| | --| EDF-DER-IPN-SID- T T I | --| Intranet: http://cln46gb | --| Bureau N-023 e-mail: p.obry@der.edf.fr | --| 1 Av G�n�ral de Gaulle voice : +33-1-47.65.50.91 | --| 92141 Clamart CEDEX fax : +33-1-47.65.50.07 | --| FRANCE | --|------------------------------------------------------------ --| --| http://perso.wanadoo.fr/pascal.obry --| --| "The best way to travel is by means of imagination" ^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: ada writing guide 2000-04-14 0:00 ` Pascal Obry @ 2000-04-14 0:00 ` Ted Dennison 2000-04-14 0:00 ` Pascal Obry 0 siblings, 1 reply; 76+ messages in thread From: Ted Dennison @ 2000-04-14 0:00 UTC (permalink / raw) In article <8d6hjn$j9p$1@clnews.edf.fr>, "Pascal Obry" <p.obry@der.edf.fr> wrote: > This is addressed in latest GLIDE release where you can build an > exception list. This way you can write tbd and EMACS will > automagically capitalize it to TBD ! You just write it the way you > want once and you put it (with a magic key :) in your exception file > that's all. Perfect! I'd considered writing some elisp to do exactly that myself, but it didn't really look like a one-day job. Is the code that accomplishes this elisp that comes with GLIDE, or an actual integral part of GLIDE? It'd be a shame if folks had to use Gnat's IDE to get access to it. -- T.E.D. http://www.telepath.com/~dennison/Ted/TED.html Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: ada writing guide 2000-04-14 0:00 ` Ted Dennison @ 2000-04-14 0:00 ` Pascal Obry 2000-04-17 0:00 ` Ted Dennison 0 siblings, 1 reply; 76+ messages in thread From: Pascal Obry @ 2000-04-14 0:00 UTC (permalink / raw) [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain, Size: 1252 bytes --] Ted Dennison a �crit dans le message <8d76vj$9jt$1@nnrp1.deja.com>... >In article <8d6hjn$j9p$1@clnews.edf.fr>, > "Pascal Obry" <p.obry@der.edf.fr> wrote: >> This is addressed in latest GLIDE release where you can build an >> exception list. This way you can write tbd and EMACS will >> automagically capitalize it to TBD ! You just write it the way you >> want once and you put it (with a magic key :) in your exception file >> that's all. > >Perfect! I'd considered writing some elisp to do exactly that myself, >but it didn't really look like a one-day job. Is the code that >accomplishes this elisp that comes with GLIDE, or an actual integral >part of GLIDE? It'd be a shame if folks had to use Gnat's IDE to get >access to it. This is already implemented in the latest Ada mode I think. Have a look at version 3.4b of the Ada mode available here: http://www.ada-france.org/ada-mode/ Pascal. --|------------------------------------------------------ --| Pascal Obry Team-Ada Member --| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE --|------------------------------------------------------ --| http://perso.wanadoo.fr/pascal.obry --| --| "The best way to travel is by means of imagination" ^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: ada writing guide 2000-04-14 0:00 ` Pascal Obry @ 2000-04-17 0:00 ` Ted Dennison 2000-04-17 0:00 ` Florian Weimer 0 siblings, 1 reply; 76+ messages in thread From: Ted Dennison @ 2000-04-17 0:00 UTC (permalink / raw) In article <8d7uak$1d1$1@wanadoo.fr>, "Pascal Obry" <p.obry@wanadoo.fr> wrote: > This is already implemented in the latest Ada mode I think. Have a > look at version 3.4b of the Ada mode available here: Downloaded, installed, and works. Thanks a bunch. I do have one (minor) problem with the implementation, though. It looks like the exception file is read once at startup into an internal buffer. When someone adds an entry, it is their internal copy that is added to, then written to disk. If another user changed that file in the meantime, their changes are lost. This, combined with the advice for projects to keep one master file which everyone uses, could lead to a big mess. I warned everyone here to load before they do any adds, but I'm afraid its going to be easy advice to forget. -- T.E.D. http://www.telepath.com/~dennison/Ted/TED.html Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: ada writing guide 2000-04-17 0:00 ` Ted Dennison @ 2000-04-17 0:00 ` Florian Weimer 2000-04-17 0:00 ` Ted Dennison 0 siblings, 1 reply; 76+ messages in thread From: Florian Weimer @ 2000-04-17 0:00 UTC (permalink / raw) Ted Dennison <dennison@telepath.com> writes: > I do have one (minor) problem with the implementation, though. It looks > like the exception file is read once at startup into an internal buffer. > When someone adds an entry, it is their internal copy that is added to, > then written to disk. If another user changed that file in the > meantime, their changes are lost. This, combined with the advice for > projects to keep one master file which everyone uses, could lead to a > big mess. Put the file under version control. I'm amazed to see that there are still projects with multiple developers which do not use it. ;) ^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: ada writing guide 2000-04-17 0:00 ` Florian Weimer @ 2000-04-17 0:00 ` Ted Dennison 2000-04-17 0:00 ` Ted Dennison ` (3 more replies) 0 siblings, 4 replies; 76+ messages in thread From: Ted Dennison @ 2000-04-17 0:00 UTC (permalink / raw) In article <87em84vavt.fsf@deneb.cygnus.argh.org>, Florian Weimer <fw-usenet@deneb.cygnus.argh.org> wrote: > Ted Dennison <dennison@telepath.com> writes: > > > I do have one (minor) problem with the implementation, though. It > > looks like the exception file is read once at startup into an > > internal buffer. When someone adds an entry, it is their internal > > copy that is added to, then written to disk. If another user > > changed that file in the meantime, their changes are lost. This, > > combined with the advice for projects to keep one master file which > > everyone uses, could lead to a big mess. > > Put the file under version control. I'm amazed to see that there are > still projects with multiple developers which do not use it. ;) > We do of course. I thought there was about a %30 chance someone would bring this up. :-( That is the first thing I thought of as well. However, further thought will show you that it won't really solve the problem. It just gives us a recovery option from particularly bad losses, at the cost of a lot of overhead around any changes. To help you see, cosider the following scenario: Monday Fred opens up an emacs session. Tuesday, Joe opens up an emacs session and adds 3 capitalizations. Wednesday, Joe adds 3 more capitalizations Thursday, Joe adds 3 more capitalizations Friday, Fred adds 5 capitalizations (wiping out all of 6 Joe's) Monday, Joe adds 4 more capitalizations (wiping out Fred's 5) etc. With revision control, we have: Monday Fred opens up an emacs session. Tuesday, Joe opens up an emacs session, checks out the cap file, adds 3 capitalizations, and checks back in the cap file. Wednesday, Joe checks out the cap file, adds 3 more capitalizations, and checks back in the cap file. Thursday, Joe checks out the cap file, adds 3 more capitalizations, and checks back in the cap file. Friday, Fred checks out the cap file, adds 5 capitalizations, and checks back in the cap file. (wiping out all 6 of Joe's) Monday, Joe checks out the cap file, adds 4 more capitalizations, and checks back in the cap file (wiping out Fred's 5) etc. -- T.E.D. http://www.telepath.com/~dennison/Ted/TED.html Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: ada writing guide 2000-04-17 0:00 ` Ted Dennison @ 2000-04-17 0:00 ` Ted Dennison 2000-04-18 0:00 ` Robert Dewar ` (2 subsequent siblings) 3 siblings, 0 replies; 76+ messages in thread From: Ted Dennison @ 2000-04-17 0:00 UTC (permalink / raw) In article <8dfpj7$crs$1@nnrp1.deja.com>, Ted Dennison <dennison@telepath.com> wrote: > Tuesday, Joe opens up an emacs session and adds 3 capitalizations. > Wednesday, Joe adds 3 more capitalizations > Thursday, Joe adds 3 more capitalizations > Friday, Fred adds 5 capitalizations (wiping out all of 6 Joe's) Eeeah. That adds up to *9* capitalizations, not 6. Where's that english sentence compiler when I need it?.... -- T.E.D. http://www.telepath.com/~dennison/Ted/TED.html Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: ada writing guide 2000-04-17 0:00 ` Ted Dennison 2000-04-17 0:00 ` Ted Dennison @ 2000-04-18 0:00 ` Robert Dewar 2000-04-18 0:00 ` Ted Dennison 2000-04-20 0:00 ` Samuel T. Harris 2000-04-20 0:00 ` Emmanuel Briot 3 siblings, 1 reply; 76+ messages in thread From: Robert Dewar @ 2000-04-18 0:00 UTC (permalink / raw) In article <8dfpj7$crs$1@nnrp1.deja.com>, Ted Dennison <dennison@telepath.com> wrote: > checks back in the cap file. (wiping out all 6 of Joe's) > Monday, Joe checks out the cap file, adds 4 more capitalizations, and > checks back in the cap file (wiping out Fred's 5) > etc. This is incomprehensible, with proper revision control no one ever wipes out anyone else's work. If individuals need variants, a proper revision control system accomodates this. This sounds like a comment from a VERY uncontrolled environment. Ted, what configuration control software are you using? Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: ada writing guide 2000-04-18 0:00 ` Robert Dewar @ 2000-04-18 0:00 ` Ted Dennison 2000-04-18 0:00 ` Robert Dewar 0 siblings, 1 reply; 76+ messages in thread From: Ted Dennison @ 2000-04-18 0:00 UTC (permalink / raw) In article <8dgk8i$ak4$1@nnrp1.deja.com>, Robert Dewar <robert_dewar@my-deja.com> wrote: > This is incomprehensible, with proper revision control no one > ever wipes out anyone else's work. (sigh) You seem to be missing the point too. Yes, the old versions are still there. But in order for version 1.2 to be based on version 1.1, the person who created 1.2 had to have been working from version 1.1 (and not 1.0). Right? If this were a normal source file, then emacs would at worst warn the user that the file has changed on disk before it allows them to edit it. A similar warning would be given before the file can be saved. But the exception file is *not* a normal source file (unless you load and hand-edit the file, I guess), and no such warnings occur. Try it yourself with two emacs sessions if you don't believe me. Throw RCS into the mix, and verify for yourself that the same thing happens, only with saved copies. -- T.E.D. http://www.telepath.com/~dennison/Ted/TED.html Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: ada writing guide 2000-04-18 0:00 ` Ted Dennison @ 2000-04-18 0:00 ` Robert Dewar 2000-04-18 0:00 ` Ted Dennison 0 siblings, 1 reply; 76+ messages in thread From: Robert Dewar @ 2000-04-18 0:00 UTC (permalink / raw) In article <8dhqi7$jv3$1@nnrp1.deja.com>, Ted Dennison <dennison@telepath.com> wrote: > Yes, the old versions are still there. But in order for version 1.2 to > be based on version 1.1, the person who created 1.2 had to have been > working from version 1.1 (and not 1.0). Right? Robert is a bit incredulous here (and again wonders what kind of configuration management is used in Ted's company). Of *course* if you update a file, you have to worry about not blotting out changes done to previous versions. This is achieved in one of two ways 1. You merge changes yourself, always going from the most recently checked in version. 2. You use an automatic merge facility such as that provided in CVS. I personally prefer the first approach, but many find the second approach fine. T.E.D. seems to be describing a system in which people use neither approach, and merrily destroy one anothers fixes by updating old versions. I would NOT call this version control at all. Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: ada writing guide 2000-04-18 0:00 ` Robert Dewar @ 2000-04-18 0:00 ` Ted Dennison 2000-04-18 0:00 ` Brian Courtney 2000-04-19 0:00 ` Florian Weimer 0 siblings, 2 replies; 76+ messages in thread From: Ted Dennison @ 2000-04-18 0:00 UTC (permalink / raw) In article <8dhuuu$ou5$1@nnrp1.deja.com>, Robert Dewar <robert_dewar@my-deja.com> wrote: > In article <8dhqi7$jv3$1@nnrp1.deja.com>, > Ted Dennison <dennison@telepath.com> wrote: > T.E.D. seems to be describing a system in which people use > neither approach, and merrily destroy one anothers fixes by > updating old versions. I would NOT call this version control > at all. I must be a really crappy communicator if a complaint about an emacs configuration file being difficult to control from long-lived sessions comes off this horribly off-target. I guess I should quit while I'm behind, but... Substitute "emacs" for "people", and "exception file changes" for "fixes", and that's my exact problem with it. Perhaps if I rephrase it this way: How easy is it for a "fix" to get wiped out using emacs? I have used 6 different revision control systems, but the following process will work with all of them (ClearCase requires custom emacs lisp files, but they exist). First, for a normal source file: The file has to be explicitly opened in an emacs buffer. The file has to be updated outside of the emacs buffer, while the emacs session remains running. The updated version has to be checked in. The emacs user has to check the source file out *outside* of emacs, while it is already in the emacs buffer. Checking it out inside of emacs would cause the buffer to get updated with the latest copy. If the buffer was read-only when the user loaded it, the user must manually change it to read/write without realoading the file. This can be done, but few would routinely do it that way with managed files. Next the user would have to edit the buffer (containing the older version). This will cause emacs to dispaly a prompt asking if they really want to edit, as this isn't the latest version. The user *must* type a "y" to proceed. Next the user must save the buffer. Again, a warning will be displayed stating that this isn't the latest version. The user must type a y at the prompt (which they wouldn't normally have to do) to save the file. A backup of the old file will be created by emacs. Finally, the user must check in the buffer (inside or outside of emacs). Reading over all this, it should be clear to anyone that there is *no way* all this is going to happen on accident. Now, for an exceptions file: The user starts up emacs A second user (or possibly the same user with a second emacs session) checks the file out. The second user modifies it somehow. The second user checks the file in. The first user checks the file out. The first user types Ctrl-C Ctrl-Y in their emacs session. The first user checks the file in. No warnings are given, no backups are made. The old version is over-written. Even for those who know the danger, this would be easy to accidentally do. Again, if anyone is still confused, I'm *not* saying this can happen with normal source files. Its a problem with the emacs Ada-mode capitalization files, which is cheifly an artifact of the fact that the tool that uses them never rereads them once it has started. It would be roughly equivalent to sources only you had to issue some special command or reboot every time you wanted your compiler to read the latest source files from disk. -- T.E.D. http://www.telepath.com/~dennison/Ted/TED.html Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: ada writing guide 2000-04-18 0:00 ` Ted Dennison @ 2000-04-18 0:00 ` Brian Courtney 2000-04-19 0:00 ` Florian Weimer 2000-04-19 0:00 ` Brian Courtney 2000-04-19 0:00 ` Florian Weimer 1 sibling, 2 replies; 76+ messages in thread From: Brian Courtney @ 2000-04-18 0:00 UTC (permalink / raw) Ted Dennison wrote: > In article <8dhuuu$ou5$1@nnrp1.deja.com>, > Robert Dewar <robert_dewar@my-deja.com> wrote: > > In article <8dhqi7$jv3$1@nnrp1.deja.com>, > > Ted Dennison <dennison@telepath.com> wrote: > > > T.E.D. seems to be describing a system in which people use > > neither approach, and merrily destroy one anothers fixes by > > updating old versions. I would NOT call this version control > > at all. Perhaps I can clear things up a bit here. Teds complaint stems from the fact that the implementation of Emacs ada-mode assumes that each user has their own copy of a special capitalization exception file (used to overide the default capitalization rules used by the editor). If each user has their own copy, then there is no problem. Think of it like a .cshrc file were each user defines their own customized commands, aliases, etc...). If a single 'common' file is used (shared among several users) to ensure that all capitalization is consistent, there is a chance that changes to the capitalization exception file can be lost, due to the fact that there is no protection built into Emacs to detect if someone else has modified the file since it was last read in. Whether the file is under configuration control or not is irrelevant in this situation. This is a special configuration file used by the Emacs editor that can be updated on-the-fly by a user. Since the implementation of ada-mode modifies to its "potentialy out of date" internal copy of the exception file before writting it to disk, someone elses updates to the same file (made after your Emacs session read the file) can be lost. Ted was simply giving his opinion on a possible pitfall associated with using ada-mode and a *single* capitialization exception file. I do not believe this is a CM issue. CM comes into play *after* the updates have been made to a file. A CM tool can not prevent you from accidently deleting lines from a file and then saving them. CM will, however, allow you to restore the file to the last controlled version, but all the intermediate changes made outside the CM tool (while you are still editing the file) are not controlled. This is the situtation we are dealing with. Ted, There are two possible solutions that I see 1. make the capitalization file read-only and have the users submit changes to the file through the owner. Not the best solution. 2. change ada-mode.el to re-read the exception file and update the internal copy just before it saves the file. NOTE: There may still be small chance that changes will be lost with this approach, but very very unlikely. ex, (NOTE: I have not tried this, but it should work). from ada-create-case-exception ;; Save the list in the file (find-file (expand-file-name ada-case-exception-file)) (erase-buffer) ;; force update of ada-case-exception (reread exception file) (ada-case-read-exceptions) ;; this line added from original (mapcar '(lambda (x) (insert (car x) "\n")) ada-case-exception) (save-buffer) (kill-buffer nil) ) ^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: ada writing guide 2000-04-18 0:00 ` Brian Courtney @ 2000-04-19 0:00 ` Florian Weimer 2000-04-19 0:00 ` Brian Courtney 1 sibling, 0 replies; 76+ messages in thread From: Florian Weimer @ 2000-04-19 0:00 UTC (permalink / raw) Brian Courtney <bcourtn@hercii.mar.lmco.com> writes: > I do not believe this is a CM issue. CM comes into play *after* > the updates have been made to a file. Some CM flavors give each user his own set of source files. I'm surprised such systems aren't more widespread. There are numerous advantages with this approach, and only few drawbacks. ^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: ada writing guide 2000-04-18 0:00 ` Brian Courtney 2000-04-19 0:00 ` Florian Weimer @ 2000-04-19 0:00 ` Brian Courtney 1 sibling, 0 replies; 76+ messages in thread From: Brian Courtney @ 2000-04-19 0:00 UTC (permalink / raw) Brian Courtney wrote: > 2. change ada-mode.el to re-read the exception file and update > the internal copy just before it saves the file. NOTE: There may > still be small chance that changes will be lost with this approach, > but very very unlikely. > > ex, (NOTE: I have not tried this, but it should work). Famous last words! > > > from ada-create-case-exception > > ;; Save the list in the file > (find-file (expand-file-name ada-case-exception-file)) > (erase-buffer) > ;; force update of ada-case-exception (reread exception file) > (ada-case-read-exceptions) ;; this line added from original > (mapcar '(lambda (x) (insert (car x) "\n")) ada-case-exception) > (save-buffer) > (kill-buffer nil) > ) That's what I get for not testing it myself. Add the call to ada-case-read-exceptions to the first line of the ada-create-case-exception function and that should solve your problem (I tested it this time and it seems to work). ^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: ada writing guide 2000-04-18 0:00 ` Ted Dennison 2000-04-18 0:00 ` Brian Courtney @ 2000-04-19 0:00 ` Florian Weimer 2000-04-19 0:00 ` Ted Dennison ` (2 more replies) 1 sibling, 3 replies; 76+ messages in thread From: Florian Weimer @ 2000-04-19 0:00 UTC (permalink / raw) Ted Dennison <dennison@telepath.com> writes: > No warnings are given, no backups are made. The old version is > over-written. Even for those who know the danger, this would be easy to > accidentally do. This can't happen with systems like CVS where each user works on his private copy of the source files. The master files are often not directly accessible. Problem solved. ;) ^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: ada writing guide 2000-04-19 0:00 ` Florian Weimer @ 2000-04-19 0:00 ` Ted Dennison 2000-04-24 0:00 ` Samuel T. Harris 2000-04-19 0:00 ` Robert Dewar 2000-04-24 0:00 ` Samuel T. Harris 2 siblings, 1 reply; 76+ messages in thread From: Ted Dennison @ 2000-04-19 0:00 UTC (permalink / raw) In article <874s8yeg81.fsf@deneb.cygnus.argh.org>, Florian Weimer <fw-usenet@deneb.cygnus.argh.org> wrote: > Ted Dennison <dennison@telepath.com> writes: > > > No warnings are given, no backups are made. The old version is > > over-written. Even for those who know the danger, this would be easy to > > accidentally do. > > This can't happen with systems like CVS where each user works on his > private copy of the source files. The master files are often not > directly accessible. Problem solved. ;) Hmm. I use CVS at home, but I guess that's not multiuser (yet, perhaps It'll be that way when my kids are older :-) ). I'm still not convinced CVS wouldn't have the problem too. But at least the process give you one hint. I see it working this way. User A does a "cvs checkout" of the repository User B does a "cvs checkout" of the repository User A starts up emacs (which reads the exception file into memory). User B starts up emacs (which reads the exception file into memory). User A hits Ctrl-C Ctrl-Y User A does a "cvs commit" on the exception file User B finds out there were changes, and does a "cvs update" User B hits Ctrl-C Ctrl-Y (unknowingly wiping out user A's changes) User B does a "cvs commit" At least this way, there is a manual updating step in there, where the wise user could say, "I'd better bring my emacs up to date, just to be safe." But it'd still be awfully easy to forget, or overlook a running session somewhere. -- T.E.D. http://www.telepath.com/~dennison/Ted/TED.html Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: ada writing guide 2000-04-19 0:00 ` Ted Dennison @ 2000-04-24 0:00 ` Samuel T. Harris 0 siblings, 0 replies; 76+ messages in thread From: Samuel T. Harris @ 2000-04-24 0:00 UTC (permalink / raw) Ted Dennison wrote: > > In article <874s8yeg81.fsf@deneb.cygnus.argh.org>, > Florian Weimer <fw-usenet@deneb.cygnus.argh.org> wrote: > > Ted Dennison <dennison@telepath.com> writes: > > > > > No warnings are given, no backups are made. The old version is > > > over-written. Even for those who know the danger, this would be easy > to > > > accidentally do. > > > > This can't happen with systems like CVS where each user works on his > > private copy of the source files. The master files are often not > > directly accessible. Problem solved. ;) > > Hmm. I use CVS at home, but I guess that's not multiuser (yet, perhaps > It'll be that way when my kids are older :-) ). > > I'm still not convinced CVS wouldn't have the problem too. But at least > the process give you one hint. I see it working this way. > > User A does a "cvs checkout" of the repository > User B does a "cvs checkout" of the repository Here is your problem. Any tool which does not provide some check on multiple check-outs and a way to prevent then is seriously broken IMO. Access controls become more and more important as project size grows, or the separation between developers increases. Multiple changes to the same source simply cannot be allowed. Merging is just not a viable mitigator to this chaotic sequence of events. > User A starts up emacs (which reads the exception file into memory). > User B starts up emacs (which reads the exception file into memory). > User A hits Ctrl-C Ctrl-Y > User A does a "cvs commit" on the exception file > User B finds out there were changes, and does a "cvs update" > User B hits Ctrl-C Ctrl-Y (unknowingly wiping out user A's changes) With access controls, this would not happen because the B's check-out would have failed. This mentality of letting anyone do anything and merge it all together later is simply frought with too many pitfalls. > User B does a "cvs commit" > > At least this way, there is a manual updating step in there, where the > wise user could say, "I'd better bring my emacs up to date, just to be > safe." But it'd still be awfully easy to forget, or overlook a running > session somewhere. There in lies the rub. Merging later depends upon that later actually coming. Better to prevent multiple changes up front. User A and B have a file based upon some common version. User A checks it out, makes changes, and then checks it in. User B checks it out and fails because he does not have the latest version. User B can not attempt the check out again and force the system to ignore User A's changes (B had better know what he is doing here) or User B can accept the changes from User A and then check out the file. > > -- > T.E.D. -- Samuel T. Harris, Principal Engineer Raytheon, Aerospace Engineering Services "If you can make it, We can fake it!" ^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: ada writing guide 2000-04-19 0:00 ` Florian Weimer 2000-04-19 0:00 ` Ted Dennison @ 2000-04-19 0:00 ` Robert Dewar 2000-04-20 0:00 ` Ted Dennison 2000-04-24 0:00 ` Samuel T. Harris 2 siblings, 1 reply; 76+ messages in thread From: Robert Dewar @ 2000-04-19 0:00 UTC (permalink / raw) In article <874s8yeg81.fsf@deneb.cygnus.argh.org>, Florian Weimer <fw-usenet@deneb.cygnus.argh.org> wrote: > Ted Dennison <dennison@telepath.com> writes: > > > No warnings are given, no backups are made. The old version is > > over-written. Even for those who know the danger, this would be easy to > > accidentally do. > > This can't happen with systems like CVS where each user works on his > private copy of the source files. The master files are often not > directly accessible. Problem solved. ;) Exactly! I find it extraordinary that the master files should ever be directly accessible. I would find a system where Ted's scenario can occur quite unacceptable! Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: ada writing guide 2000-04-19 0:00 ` Robert Dewar @ 2000-04-20 0:00 ` Ted Dennison 2000-04-20 0:00 ` Florian Weimer 0 siblings, 1 reply; 76+ messages in thread From: Ted Dennison @ 2000-04-20 0:00 UTC (permalink / raw) Robert Dewar wrote: > In article <874s8yeg81.fsf@deneb.cygnus.argh.org>, > Florian Weimer <fw-usenet@deneb.cygnus.argh.org> wrote: > Exactly! I find it extraordinary that the master files should > ever be directly accessible. I would find a system where Ted's > scenario can occur quite unacceptable! I have already explained that this scenario can occur just as easily when the revision control master files are not directly accessable. So you have now agreed that you find the current version of emacs Ada mode "quite unacceptable". That's a bit more extreme than my position that its just a somewhat bad problem, but at this point I'll take agreement where I can get it. :-) -- T.E.D. Home - mailto:dennison@telepath.com Work - mailto:dennison@ssd.fsi.com WWW - http://www.telepath.com/dennison/Ted/TED.html ICQ - 10545591 ^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: ada writing guide 2000-04-20 0:00 ` Ted Dennison @ 2000-04-20 0:00 ` Florian Weimer 2000-04-20 0:00 ` Ted Dennison 0 siblings, 1 reply; 76+ messages in thread From: Florian Weimer @ 2000-04-20 0:00 UTC (permalink / raw) Ted Dennison <dennison@telepath.com> writes: > I have already explained that this scenario can occur just as easily > when the revision control master files are not directly accessable. No, you have shown that careless programmers can make a mess even if a CM system is used. For example, with CVS, a programmer cannot commit his changes to a file if they are based on an outdated version (i.e. a newer one has been committed to the repository since he first checked out the file). He has to adapt his changes to match the newest version of the file first. Of course, if the programmer doesn't handle this situation properly, changes to the file might get lost. But if a programmer can't cope with this situation (the simple format of the file makes merging the changes particularly easy), you are soon going to have much severe problems than lost entries in a exception list controlling identifier casing. > So you have now agreed that you find the current version of emacs > Ada mode "quite unacceptable". I think Robert talked about CM systems. ;) ^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: ada writing guide 2000-04-20 0:00 ` Florian Weimer @ 2000-04-20 0:00 ` Ted Dennison 0 siblings, 0 replies; 76+ messages in thread From: Ted Dennison @ 2000-04-20 0:00 UTC (permalink / raw) Florian Weimer wrote: > Ted Dennison <dennison@telepath.com> writes: > > > I have already explained that this scenario can occur just as easily > > when the revision control master files are not directly accessable. > > No, you have shown that careless programmers can make a mess even if a > CM system is used. For example, with CVS, a programmer cannot commit > his changes to a file if they are based on an outdated version (i.e. a > newer one has been committed to the repository since he first checked > out the file). He has to adapt his changes to match the newest > version of the file first. Of course, if the programmer doesn't Since I don't see any specifics in my post addressed, I'll try to do it for you myself. One of us is missing something. It could well have been me: 1. User does checkout of cvs repostitory 2. User starts emacs, which loads the exception file into a local buffer. 3. Exception file changes outside of emacs, and is updated. 4. User realizes that lots of stuff is out of date (not nessecarily just exception file), so he does a "cvs update". Now as far as CVS is concerned, user is looking at the most up-to date version. However, his emacs is still working from the old exception file. 5. User sees a new exception, and does a Ctrl-C Ctrl-Y, which saves the *old* version of the exception file to disk, with his one update 6. User wants his new exception saved in cvs, so he does a "cvs commit". Cvs has no problem with this, as it thinks the user was working from the latest version. Now the result of this process is that User just wiped out the previous version revision-controlled changes to the exception file. So what are your *specific* problems with this scenario? You said: * "Careless programmers can make a mess, even if CM is used". So perhaps you think that User above was being careless in not routinely doing an update of emacs' internal exceptions buffer before doing the write? That is perhaps a reasonable position. But in that case, why bring up revision control at all? Revision control doesn't even materially change the mistake a "careless" programmer has to make. It just adds some steps to either side of it. Plus, if the way to *not* be careless is to take one extra step (reloading the exceptions buffer) every time it is saved, what's wrong with advocating that emacs do both instead of just the one? Why leave it open to easy carelessnes? Why make the user perform two steps (forgetting one of which will sliently hose his file) every single time? * "with CVS, a programmer cannot commit his changes to a file if they are based on an outdated version". This is true only in the abstract. All CVS does is force the programmer to have issued a "cvs update" from the most recent version before he does a "commit". CVS does not force emacs to reload its local copy of that file. Emacs, won't notice the problem on its side, like it would for a normal file. CVS has no way of telling that the file used for "commit" really was based off that "update" file. If emacs wipes out that most recent version with something based off an older version, CVS can't help you. -- T.E.D. Home - mailto:dennison@telepath.com Work - mailto:dennison@ssd.fsi.com WWW - http://www.telepath.com/dennison/Ted/TED.html ICQ - 10545591 ^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: ada writing guide 2000-04-19 0:00 ` Florian Weimer 2000-04-19 0:00 ` Ted Dennison 2000-04-19 0:00 ` Robert Dewar @ 2000-04-24 0:00 ` Samuel T. Harris 2000-04-24 0:00 ` Robert A Duff 2000-04-25 0:00 ` Robert Dewar 2 siblings, 2 replies; 76+ messages in thread From: Samuel T. Harris @ 2000-04-24 0:00 UTC (permalink / raw) Florian Weimer wrote: > > Ted Dennison <dennison@telepath.com> writes: > > > No warnings are given, no backups are made. The old version is > > over-written. Even for those who know the danger, this would be easy to > > accidentally do. > > This can't happen with systems like CVS where each user works on his > private copy of the source files. The master files are often not > directly accessible. Problem solved. ;) When programming in the large or huge, every developer simply can't have his own copy of the entire project. There just isn't enough disk space available. Therefore, a divide and conquer mentality is in order where various groups of developers depend upon shared "releases" of the other groups. This is where good configuration management tools diverge from the simple domain of version and access control. -- Samuel T. Harris, Principal Engineer Raytheon, Aerospace Engineering Services "If you can make it, We can fake it!" ^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: ada writing guide 2000-04-24 0:00 ` Samuel T. Harris @ 2000-04-24 0:00 ` Robert A Duff 2000-04-25 0:00 ` Robert Dewar 1 sibling, 0 replies; 76+ messages in thread From: Robert A Duff @ 2000-04-24 0:00 UTC (permalink / raw) "Samuel T. Harris" <samuel_t_harris@Raytheon.com> writes: > > Florian Weimer wrote: > > > > Ted Dennison <dennison@telepath.com> writes: > > > > > No warnings are given, no backups are made. The old version is > > > over-written. Even for those who know the danger, this would be easy to > > > accidentally do. > > > > This can't happen with systems like CVS where each user works on his > > private copy of the source files. The master files are often not > > directly accessible. Problem solved. ;) > > When programming in the large or huge, every developer simply > can't have his own copy of the entire project. There just isn't > enough disk space available. Therefore, a divide and conquer > mentality is in order where various groups of developers > depend upon shared "releases" of the other groups. This is where > good configuration management tools diverge from the simple > domain of version and access control. CVS supports that model, too. (But this is a separate issue -- neither CVS nor any other CM system solves the editor-related bug we were talking about.) - Bob ^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: ada writing guide 2000-04-24 0:00 ` Samuel T. Harris 2000-04-24 0:00 ` Robert A Duff @ 2000-04-25 0:00 ` Robert Dewar 2000-04-27 0:00 ` Samuel T. Harris 1 sibling, 1 reply; 76+ messages in thread From: Robert Dewar @ 2000-04-25 0:00 UTC (permalink / raw) In article <390483D0.3AE3A577@Raytheon.com>, "Samuel T. Harris" <samuel_t_harris@Raytheon.com> wrote: > When programming in the large or huge, every developer simply > can't have his own copy of the entire project. I agree with that for many reasons. > There just isn't enough disk space available. But that's a week argument these days, when you can get 90 gigs of Raid 5 storage accessible from any NT or Unix machine for under $3000. Any organization that let's itself be limited by disk space is wasting the time of its programmers! The arguments for avoiding unnecssary documentation are organizational rather than resource based in my view. Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: ada writing guide 2000-04-25 0:00 ` Robert Dewar @ 2000-04-27 0:00 ` Samuel T. Harris 0 siblings, 0 replies; 76+ messages in thread From: Samuel T. Harris @ 2000-04-27 0:00 UTC (permalink / raw) Robert Dewar wrote: > > In article <390483D0.3AE3A577@Raytheon.com>, > "Samuel T. Harris" <samuel_t_harris@Raytheon.com> wrote: > > When programming in the large or huge, every developer simply > > can't have his own copy of the entire project. > > I agree with that for many reasons. > > > There just isn't enough disk space available. > > But that's a week argument these days, when you can get 90 > gigs of Raid 5 storage accessible from any NT or Unix machine > for under $3000. Any organization that let's itself be > limited by disk space is wasting the time of its programmers! > > The arguments for avoiding unnecssary documentation are > organizational rather than resource based in my view. > > Sent via Deja.com http://www.deja.com/ > Before you buy. Please be careful for careless use of the word "any". We have 300 developers, 7000 program units, 150 separate compilation areas which all have to be pieced together. Even with a terabyte RAID array we are still running out! At it cost several more zeros than $3000. Huge project, numerous parallel development, maintenance and operational paths, 300 developers, and the need for reasonable back-up performance. You do the math! Disk space is a limiting factor! -- Samuel T. Harris, Principal Engineer Raytheon, Aerospace Engineering Services "If you can make it, We can fake it!" ^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: ada writing guide 2000-04-17 0:00 ` Ted Dennison 2000-04-17 0:00 ` Ted Dennison 2000-04-18 0:00 ` Robert Dewar @ 2000-04-20 0:00 ` Samuel T. Harris 2000-04-20 0:00 ` Ted Dennison 2000-04-20 0:00 ` Emmanuel Briot 3 siblings, 1 reply; 76+ messages in thread From: Samuel T. Harris @ 2000-04-20 0:00 UTC (permalink / raw) Ted Dennison wrote: > > With revision control, we have: > > Monday Fred opens up an emacs session. > Tuesday, Joe opens up an emacs session, checks out the cap file, adds > 3 capitalizations, and checks back in the cap file. > Wednesday, Joe checks out the cap file, adds 3 more capitalizations, > and checks back in the cap file. > Thursday, Joe checks out the cap file, adds 3 more capitalizations, > and checks back in the cap file. Any version control system which allows Fred to simply check-out the file without warning him that his content is no longer based on the latest version is seriously broken! This is a basic access control feature. If you want this protection, then support of this feature becames a primary tool selection requirement! > Friday, Fred checks out the cap file, adds 5 capitalizations, and > checks back in the cap file. (wiping out all 6 of Joe's) > Monday, Joe checks out the cap file, adds 4 more capitalizations, and > checks back in the cap file (wiping out Fred's 5) > etc. > Our configuration management tool fails on Freds Friday check-out because the version upon which he is basing his check-out is no longer the latest version available. At that point, Fred can try again and either accept the latest version before the check-out (thus preserving Joe's changes) or forcing his version to become the latest (because he KNOWS Joe's changes are bogus). -- Samuel T. Harris, Principal Engineer Raytheon, Aerospace Engineering Services "If you can make it, We can fake it!" ^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: ada writing guide 2000-04-20 0:00 ` Samuel T. Harris @ 2000-04-20 0:00 ` Ted Dennison 2000-04-21 0:00 ` Robert Dewar ` (2 more replies) 0 siblings, 3 replies; 76+ messages in thread From: Ted Dennison @ 2000-04-20 0:00 UTC (permalink / raw) "Samuel T. Harris" wrote: > Any version control system which allows Fred to simply check-out > the file without warning him that his content is no longer > based on the latest version is seriously broken! This is a > basic access control feature. If you want this protection, > then support of this feature becames a primary tool selection > requirement! (Sigh). You are talking about a different revision control setup than I was in the quoted post (one in which the latest source is always visible, unless a local copy is checked out for editing). I addressed the (CVS) style you are referring to in another post. Suffice to say, the problem still exists in the setup you are talking about too (unless you have some kind of revision control system that notices that emacs has an obsolete copy loaded in its internal buffer). It seems like a lot of heat is getting generated on this issue due to misunderstandings about how different revision control systems work. The tragic part of this is that it doesn't matter at all what style of RCS you are using. We are *not* talking about external files here, but a buffer internal to emacs that never again gets checked against the file it was loaded from. No gyration done with external files can *possibly* solve this problem. Clearly the right solution to this problem (emacs checking the file for changes before writing it back out), has already been arrived at and implemented. So I don't see much point in continuing to sit here and argue over whether the problem exists. If the maintainer of the emacs ada mode saw that it exsits, and thought it was enough of a problem that it warranted fixing by the next revision, that's good enough for me. If anyone still feels compelled to continue this discussion, please at least do me the service of writing down your own scenario that shows how this won't be a problem. I feel like I'm swinging at the wind here. -- T.E.D. Home - mailto:dennison@telepath.com Work - mailto:dennison@ssd.fsi.com WWW - http://www.telepath.com/dennison/Ted/TED.html ICQ - 10545591 ^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: ada writing guide 2000-04-20 0:00 ` Ted Dennison @ 2000-04-21 0:00 ` Robert Dewar [not found] ` <38FFd43e.70f1bb7d@telepath.com> 2000-04-21 0:00 ` Ted Dennison 2000-04-21 0:00 ` Robert Dewar 2000-04-24 0:00 ` Samuel T. Harris 2 siblings, 2 replies; 76+ messages in thread From: Robert Dewar @ 2000-04-21 0:00 UTC (permalink / raw) In article <38FF4D28.8F946BDA@telepath.com>, Ted Dennison <dennison@telepath.com> wrote: > "Samuel T. Harris" wrote: > Ted, I think you missed my point :-) I will say again, that this kind of mistake is COMPLETELY IMPOSSIBLE for my working environment. Why, because every time I check something in, I carefully verify that the changes I am making are exactly as I expect them to be. I find any system which does not involve such careful double checks to be seriously flawed. I also carefully watch version numbers and double check BEFORE the checkin that the version number is what I expect. I quite understand that in the (to me) sloppy kind of environment you are envisioning there could be a problem, and I am glad that the emacs change helps bullet proof you from this mistake, but I will say again, that I think that any configuration control system that lets you accidentally undo changes is broken. It really all depends on what you are looking for. It sounds like you are looking for a very light weight system, where following the rule of always using emacs mostly bails you out of this kind of error, but I certainly would not rely on that in my environment. Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 76+ messages in thread
[parent not found: <38FFd43e.70f1bb7d@telepath.com>]
* Re: ada writing guide [not found] ` <38FFd43e.70f1bb7d@telepath.com> @ 2000-04-21 0:00 ` Larry Kilgallen 0 siblings, 0 replies; 76+ messages in thread From: Larry Kilgallen @ 2000-04-21 0:00 UTC (permalink / raw) Reply-To: Kilgallen@eisner.decus.org.nospam Organization: LJK Software Lines: 21 In article <38FFD43E.70F1BB7D@telepath.com>, Ted Dennison <dennison@telepath.com> writes: > Robert Dewar wrote: > >> Ted, I think you missed my point :-) I will say again, that >> this kind of mistake is COMPLETELY IMPOSSIBLE for my working >> environment. Why, because every time I check something in, I >> carefully verify that the changes I am making are exactly as >> I expect them to be. I find any system which does not involve > > Ahh, you're right, I didn't catch that part before. So you are saying > you always do a diff and visually inspect the report prior to doing a > checkin? That would indeed catch the problem. It wouldn't *prevent* the > problem, but it would catch it before you hose the baseline. The removal > of an item would stick out like a sore thumb on a diff. Personally, I'd > prefer to see the problem prevented than caught though. Remember that my > complaint was that it can happen in the first place, not that its > impossible to catch. But there is nothing to prevent me, in using an editor, from making a change that exactly removes a previous change. Therefore, human inspection of what gets checked in will always be required. ^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: ada writing guide 2000-04-21 0:00 ` Robert Dewar [not found] ` <38FFd43e.70f1bb7d@telepath.com> @ 2000-04-21 0:00 ` Ted Dennison 1 sibling, 0 replies; 76+ messages in thread From: Ted Dennison @ 2000-04-21 0:00 UTC (permalink / raw) Robert Dewar wrote: > Ted, I think you missed my point :-) I will say again, that > this kind of mistake is COMPLETELY IMPOSSIBLE for my working > environment. Why, because every time I check something in, I > carefully verify that the changes I am making are exactly as > I expect them to be. I find any system which does not involve Ahh, you're right, I didn't catch that part before. So you are saying you always do a diff and visually inspect the report prior to doing a checkin? That would indeed catch the problem. It wouldn't *prevent* the problem, but it would catch it before you hose the baseline. The removal of an item would stick out like a sore thumb on a diff. Personally, I'd prefer to see the problem prevented than caught though. Remember that my complaint was that it can happen in the first place, not that its impossible to catch. > such careful double checks to be seriously flawed. I also > carefully watch version numbers and double check BEFORE the > checkin that the version number is what I expect. Again, version number cheking wouldn't help in this situation (assuming cvs). CVS would think your version number is as it should be. Or are you talking about embedding version a CVS version code in the exception file? I guess you could do that, if it isn't the first thing on a line. -- T.E.D. Home - mailto:dennison@telepath.com Work - mailto:dennison@ssd.fsi.com WWW - http://www.telepath.com/dennison/Ted/TED.html ICQ - 10545591 ^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: ada writing guide 2000-04-20 0:00 ` Ted Dennison 2000-04-21 0:00 ` Robert Dewar @ 2000-04-21 0:00 ` Robert Dewar 2000-04-24 0:00 ` Samuel T. Harris 2 siblings, 0 replies; 76+ messages in thread From: Robert Dewar @ 2000-04-21 0:00 UTC (permalink / raw) In article <38FF4D28.8F946BDA@telepath.com>, Ted Dennison <dennison@telepath.com> wrote: > "Samuel T. Harris" wrote: > Ted, you are also not listening here. I will say again, that this kind of mistake is COMPLETELY IMPOSSIBLE for my working environment. Why, because every time I check something in, I carefully verify that the changes I am making are exactly as I expect them to be. I find any system which does not involve such careful double checks to be seriously flawed. I quite understand that in the (to me) sloppy kind of environment you are envisioning there could be a problem, and I am glad that the emacs change helps bullet proof you from this mistake, but I will say again, that I think that any configuration control system that lets you accidentally undo changes is broken. It really all depends on what you are looking for. It sounds like you are looking for a very light weight system, where following the rule of always using emacs mostly bails you out of this kind of error, but I certainly would not rely on that in my environment. Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: ada writing guide 2000-04-20 0:00 ` Ted Dennison 2000-04-21 0:00 ` Robert Dewar 2000-04-21 0:00 ` Robert Dewar @ 2000-04-24 0:00 ` Samuel T. Harris 2000-04-24 0:00 ` Robert A Duff 2 siblings, 1 reply; 76+ messages in thread From: Samuel T. Harris @ 2000-04-24 0:00 UTC (permalink / raw) Ted Dennison wrote: > > "Samuel T. Harris" wrote: > > > Any version control system which allows Fred to simply check-out > > the file without warning him that his content is no longer > > based on the latest version is seriously broken! This is a > > basic access control feature. If you want this protection, > > then support of this feature becames a primary tool selection > > requirement! > > (Sigh). You are talking about a different revision control setup than I was > in the quoted post (one in which the latest source is always visible, unless > a local copy is checked out for editing). I addressed the (CVS) style you are > referring to in another post. Suffice to say, the problem still exists in the > setup you are talking about too (unless you have some kind of revision > control system that notices that emacs has an obsolete copy loaded in its > internal buffer). > > It seems like a lot of heat is getting generated on this issue due to > misunderstandings about how different revision control systems work. The > tragic part of this is that it doesn't matter at all what style of RCS you > are using. We are *not* talking about external files here, but a buffer > internal to emacs that never again gets checked against the file it was > loaded from. No gyration done with external files can *possibly* solve this > problem. > > Clearly the right solution to this problem (emacs checking the file for > changes before writing it back out), has already been arrived at and > implemented. So I don't see much point in continuing to sit here and argue > over whether the problem exists. If the maintainer of the emacs ada mode saw > that it exsits, and thought it was enough of a problem that it warranted > fixing by the next revision, that's good enough for me. > > If anyone still feels compelled to continue this discussion, please at least > do me the service of writing down your own scenario that shows how this won't > be a problem. I feel like I'm swinging at the wind here. > I only like to add that I now understand the actual nature of your problem. I can't say why I didn't get it before but it was Emmanuel Briot's post which finally clued me into to the real problem you were talking about. Integration of CM tools with other tools is a black art. You have an integration problem which no CM tool can fully prevent. Part of our tool selection criteria is how candidate tools can be fit into our CM system. Some tools are great at what they do, but their file structures or change flows simply make them incompatible with our systems. I have felt your pain! -- Samuel T. Harris, Principal Engineer Raytheon, Aerospace Engineering Services "If you can make it, We can fake it!" ^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: ada writing guide 2000-04-24 0:00 ` Samuel T. Harris @ 2000-04-24 0:00 ` Robert A Duff 2000-04-27 0:00 ` Samuel T. Harris 0 siblings, 1 reply; 76+ messages in thread From: Robert A Duff @ 2000-04-24 0:00 UTC (permalink / raw) "Samuel T. Harris" <samuel_t_harris@Raytheon.com> writes: > I only like to add that I now understand the actual nature > of your problem. I'm glad you posted this. After seeing your previous posting, along with many others incorrectly blaming sloppy CM, I was about to start ranting and raving about "why doesn't anybody get it?!" ;-) The point is that this was a bug in Emacs, and no CM system could possibly prevent the problem. Actually, not a bug in Emacs per se, but a bug in an Emacs extension. In particular, Emacs was overwriting a (properly CM'ed) file with bogus information it (Emacs) had evilly saved in its own in-memory buffers. No CM system could prevent that -- it doesn't matter whether you like the strict-locking style, or the "hack now, merge later" style. Neither one could prevent Emacs from overwriting the (properly checked out!) file with bogus obsolete data. >... I can't say why I didn't get it before but > it was Emmanuel Briot's post which finally clued me into > to the real problem you were talking about. > > Integration of CM tools with other tools is a black art. > You have an integration problem which no CM tool can > fully prevent. No, I don't agree. The blame clearly lies on the Emacs side, not on the CM side. And (apparently) the bug has been fixed, which indicates that the author of the Emacs extension in question agrees. Let's not be wishy-washy, and blame the bug on some amorphous interface between the two. >... Part of our tool selection criteria is how > candidate tools can be fit into our CM system. Some tools > are great at what they do, but their file structures or > change flows simply make them incompatible with our systems. True, but this case is a plain-and-simple bug in Emacs (or actually an extension thereof). - Bob ^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: ada writing guide 2000-04-24 0:00 ` Robert A Duff @ 2000-04-27 0:00 ` Samuel T. Harris 0 siblings, 0 replies; 76+ messages in thread From: Samuel T. Harris @ 2000-04-27 0:00 UTC (permalink / raw) Robert A Duff wrote: > > "Samuel T. Harris" <samuel_t_harris@Raytheon.com> writes: > > > Integration of CM tools with other tools is a black art. > > You have an integration problem which no CM tool can > > fully prevent. > > No, I don't agree. The blame clearly lies on the Emacs side, not on the > CM side. And (apparently) the bug has been fixed, which indicates that > the author of the Emacs extension in question agrees. Let's not be > wishy-washy, and blame the bug on some amorphous interface between the > two. Let me clarify. By saying you have an integration problem, I did not mean to direct blame, but only to classify the kind of problem you were having. The tool IS clearly to be blamed for not taking care in the writing and rewriting of such a clearly important file. I believe we are in total agreement! > > >... Part of our tool selection criteria is how > > candidate tools can be fit into our CM system. Some tools > > are great at what they do, but their file structures or > > change flows simply make them incompatible with our systems. > > True, but this case is a plain-and-simple bug in Emacs (or actually an > extension thereof). My point here is that if any tool under consideration behaved like Emacs does/did, then that tool would find itself on the fast-track out the door! In such sitations, I don't care if its a bug or intended behavior. If I can't control the parts that need controlling, then I have no use for the tool! Now, if the tool changes behavior, then I'm glad to reconsider it. This is the happy result which you now enjoy and your enjoyment makes me happy. The world is a better place now :) -- Samuel T. Harris, Principal Engineer Raytheon, Aerospace Engineering Services "If you can make it, We can fake it!" ^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: ada writing guide 2000-04-17 0:00 ` Ted Dennison ` (2 preceding siblings ...) 2000-04-20 0:00 ` Samuel T. Harris @ 2000-04-20 0:00 ` Emmanuel Briot 2000-04-20 0:00 ` Ted Dennison 3 siblings, 1 reply; 76+ messages in thread From: Emmanuel Briot @ 2000-04-20 0:00 UTC (permalink / raw) Ted Dennison <dennison@telepath.com> writes: > I do have one (minor) problem with the implementation, though. It > looks like the exception file is read once at startup into an > internal buffer. When someone adds an entry, it is their internal > copy that is added to, then written to disk. If another user > changed that file in the meantime, their changes are lost. This, > combined with the advice for projects to keep one master file which > everyone uses, could lead to a big mess. Note that this was indeed a limitation in ada-mode 3.4b, that has been fixed about 3 or 4 months ago in the developpment version. This version is currently only available to ACT's customers (this is part of our integrated environment Glide), but will soon be included in a public version (that's a long time since I released the last version, I should do something about that :-) The fix was indeed to reread the project file before addind a new casing exception in there, which should mostly solve your problem, except maybe in the rare case where two users are trying to add an exception at exactly the same time. And even then, Emacs's internal mechanism will check and warn you that the file is already opened by another user. Emmanuel ada-mode maintainer. Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: ada writing guide 2000-04-20 0:00 ` Emmanuel Briot @ 2000-04-20 0:00 ` Ted Dennison 0 siblings, 0 replies; 76+ messages in thread From: Ted Dennison @ 2000-04-20 0:00 UTC (permalink / raw) Emmanuel Briot wrote: > Ted Dennison <dennison@telepath.com> writes: > > looks like the exception file is read once at startup into an > > internal buffer. When someone adds an entry, it is their internal > > copy that is added to, then written to disk. If another user > > changed that file in the meantime, their changes are lost. This, > > combined with the advice for projects to keep one master file which > > everyone uses, could lead to a big mess. > > Note that this was indeed a limitation in ada-mode 3.4b, that has been > fixed about 3 or 4 months ago in the developpment version. Cool. I thought this looked like a rather obvious problem, which would probably get fixed eventually. This is the kind of thing I was hoping to hear. Thanks for the good work Emmanuel (not to mention the voice of reason). -- T.E.D. Home - mailto:dennison@telepath.com Work - mailto:dennison@ssd.fsi.com WWW - http://www.telepath.com/dennison/Ted/TED.html ICQ - 10545591 ^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: ada writing guide 2000-04-13 0:00 ` Jeffrey D. Cherry 2000-04-13 0:00 ` Ted Dennison @ 2000-04-13 0:00 ` Robert A Duff 2000-04-16 0:00 ` Simon Wright 2 siblings, 0 replies; 76+ messages in thread From: Robert A Duff @ 2000-04-13 0:00 UTC (permalink / raw) After all of these opinions about what layout style people like, the answer to the original question -- is there a standard style? -- should be clear. ;-) I'll throw in an opinion: I don't like leaving a space before "(", because it leads to: Mumble (X).Bumble which implies the wrong grouping. - Bob ^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: ada writing guide 2000-04-13 0:00 ` Jeffrey D. Cherry 2000-04-13 0:00 ` Ted Dennison 2000-04-13 0:00 ` Robert A Duff @ 2000-04-16 0:00 ` Simon Wright 2000-04-16 0:00 ` Robert Dewar 2 siblings, 1 reply; 76+ messages in thread From: Simon Wright @ 2000-04-16 0:00 UTC (permalink / raw) "Jeffrey D. Cherry" <jdcherry@utech.net> writes: > Regarding Emacs ... I don't use Emacs so this behavior was a > surprise for me. I would guess that there must be a way to change > this behavior within Emacs. I don't often use the automated layout > features of my editor since my fingers already do their own > automated layout. ;) But your fingers aren't the same as mine. Mine hit the TAB key and it's all done for me. It is MUCH better to have a tool do the indentation for you and all your colleagues so you can recognise one another's work .. you probably wouldn't like APEX, you have NO control over layout! or casing, as far as I can tell! If you have a tool which will do procedure x (p1 : integer; p2 : integer); you have just what you wanted (all the parameters neatly lined up), why get antsy about that extra little paren?! (I realise we will never agree about this, BTW) ^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: ada writing guide 2000-04-16 0:00 ` Simon Wright @ 2000-04-16 0:00 ` Robert Dewar 0 siblings, 0 replies; 76+ messages in thread From: Robert Dewar @ 2000-04-16 0:00 UTC (permalink / raw) In article <x7vhfd2t3ye.fsf@pogner.demon.co.uk>, Simon Wright <simon@pogner.demon.co.uk> wrote: > It is MUCH better to have a tool do the indentation for you > and all your colleagues so you can recognise one another's > work .. you > probably wouldn't like APEX, you have NO control over layout! > or casing, as far as I can tell! I agree tools that check for consistency can be helpful, but personally I find it intolerable for the editor to do ANYTHING for me that I don't type myself, it just inteferes with my thinking, and I type fast enough that typing speed is never a bottleneck. I realize that others have different tastes, but it is important for toolsets to accomodate both viewpoints. What we do in the GNAT project is to put syntax and format checks at the checkin interface. People use their own approaches to generating the sources. Some people do indeed like to use GLIDE and have everything automated, but we don't insist on this approach. Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: ada writing guide 2000-04-13 0:00 ` Ted Dennison 2000-04-13 0:00 ` Jeffrey D. Cherry @ 2000-04-13 0:00 ` Ray Blaak 2000-04-15 0:00 ` Robert Dewar 2 siblings, 0 replies; 76+ messages in thread From: Ray Blaak @ 2000-04-13 0:00 UTC (permalink / raw) Ted Dennison <dennison@telepath.com> writes: > > procedure Foo( > > D : in out Data; > > C : in Data); > > I don't mind this so much. But there is a small problem with it. Emacs > Ada mode (at least my version of it), will try to line up the parameters > with the open paren, so unless you want to fight Emacs your whole life > to put it back, you end up with: > > procedure Foo( > D : in out Data; > C : in Data); Well, if you do this: procedure Foo (D : in out Data; C : in Data); then things look better IMHO, and you don't have to fight Emacs at all. -- Cheers, The Rhythm is around me, The Rhythm has control. Ray Blaak The Rhythm is inside me, blaak@infomatch.com The Rhythm has my soul. ^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: ada writing guide 2000-04-13 0:00 ` Ted Dennison 2000-04-13 0:00 ` Jeffrey D. Cherry 2000-04-13 0:00 ` Ray Blaak @ 2000-04-15 0:00 ` Robert Dewar 2000-04-16 0:00 ` Simon Wright 2 siblings, 1 reply; 76+ messages in thread From: Robert Dewar @ 2000-04-15 0:00 UTC (permalink / raw) In article <8d4t07$o15$1@nnrp1.deja.com>, Ted Dennison <dennison@telepath.com> wrote: > I don't mind this so much. But there is a small problem with > it. Emacs Ada mode (at least my version of it) I think you can safely assume that if I say something is standard GNAT mode, then EMACS Ada mode handles it fine (remember that the maintainer of EMACS Ada mode works for ACT/Europe :-) SO you are using an old version of EMACS. Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: ada writing guide 2000-04-15 0:00 ` Robert Dewar @ 2000-04-16 0:00 ` Simon Wright 0 siblings, 0 replies; 76+ messages in thread From: Simon Wright @ 2000-04-16 0:00 UTC (permalink / raw) Robert Dewar <robert_dewar@my-deja.com> writes: > In article <8d4t07$o15$1@nnrp1.deja.com>, > Ted Dennison <dennison@telepath.com> wrote: > > > I don't mind this so much. But there is a small problem with > > it. Emacs Ada mode (at least my version of it) > > I think you can safely assume that if I say something is > standard GNAT mode, then EMACS Ada mode handles it fine > (remember that the maintainer of EMACS Ada mode works for > ACT/Europe :-) > > SO you are using an old version of EMACS. Well, is it really the case that this procedure Foo( D : in out Data; C : in Data); is the behaviour of old Emacses? It's the way adamode-3.4b behaves on emacs 20.3 .. not all that old really. And perfectly reasonable behaviour too! if it can stop just one person using those horrible dangling open parens it will be worth it .. I tried it with a dangling close paren too, procedure Foo( D : in out Data; C : in Data ); which is way too clever, can't we come up with some scheme to make this really revolting?! ^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: ada writing guide 2000-04-13 0:00 ` Jeffrey D. Cherry 2000-04-13 0:00 ` Ted Dennison @ 2000-04-13 0:00 ` Samuel T. Harris 2000-04-13 0:00 ` Paul Graham 2 siblings, 0 replies; 76+ messages in thread From: Samuel T. Harris @ 2000-04-13 0:00 UTC (permalink / raw) "Jeffrey D. Cherry" wrote: > > Robert Dewar wrote: > > > > I find the extra ); on its own line offensive and unnatural, > > just as clear, and much easier on the eye to write > > > > > procedure Foo > > > (D : in out Data; > > > C : in Data); > > > > In GNAT we prefer to put things on a single line: > > > > > procedure Foo (D : in out Data; C : Data); > > > > If they fit comfortably on one line, and use the form with > > one line per parameter only if that is not the case. > > I quite agree that if a complete declaration can appear on one > line, it should not be arbitrarily broken up into two or more > lines. I also agree with the ");" looking silly when it's > on a line by itself. The part about "in" mode for parameters > (not quoted above, but in the original post) I would also > agree with, especially with function parameters. Now > here is where I stray ... just a bit. > > I like the following form for a subprogram declaration: > > procedure Foo( > D : in out Data; > C : in Data); > I prefer ... procedure foo ( d : in out data; -- some meaningful comment about d. c : in data -- some meaningful comment about c. ); procedure foo ( d : in out data; c : in data ) is [declarations] begin [statements] end; I find the extra white space around the parameter group natural and appealing. The comments about d and c in the subprogram specification can naturally be about the contact (a la Eiffle) assumptions. The comments about d and c in the subprogram body can be about internal assumptions or design details. -- Samuel T. Harris, Principal Engineer Raytheon, Aerospace Engineering Services "If you can make it, We can fake it!" ^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: ada writing guide 2000-04-13 0:00 ` Jeffrey D. Cherry 2000-04-13 0:00 ` Ted Dennison 2000-04-13 0:00 ` Samuel T. Harris @ 2000-04-13 0:00 ` Paul Graham 2 siblings, 0 replies; 76+ messages in thread From: Paul Graham @ 2000-04-13 0:00 UTC (permalink / raw) "Jeffrey D. Cherry" wrote: > Notice the consistency in the assignment statement. But is > it more readable to write: > > i := foobar (f) + n(2); > > This may give the reader a subtle indication that foobar is > a function call while n is an array. That would violate the principle of "referential transparency" :-) I like to keep the lexical components of a name together, so I don't put a space between a function/array name and the '('. Use of spaces with parentheses can lead to names like this: f (x).y where the tokens "(x).y" appear to be a lexical unit by themselves, unconnected to function (or array) f. Paul ^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: ada writing guide 2000-04-12 0:00 ` Robert Dewar 2000-04-13 0:00 ` Jeffrey D. Cherry @ 2000-04-13 0:00 ` Ted Dennison 1 sibling, 0 replies; 76+ messages in thread From: Ted Dennison @ 2000-04-13 0:00 UTC (permalink / raw) In article <8d2hig$7e6$1@nnrp1.deja.com>, Robert Dewar <robert_dewar@my-deja.com> wrote: > In article <8d1vhj$hdr$1@nnrp1.deja.com>, > Ted Dennison <dennison@telepath.com> wrote: > > You forgot the procedure's name. ;-) I prefer: > > procedure Foo > > (D : in out Data; > > C : in Data > > ); > > I find the use of IN redundant since it is the default, but > this is a matter of taste, as usual the critical thing is to > be consistent. I especially find the use of IN annoying in > functions. I'm beginning to come to the same conclusion on functions. You *know* they all have to be "in", so why bother saying it? If anything, that just give maintainers a false sense that the mode is under their control. For procedures, I think if you explicitly specify one mode, you should explicitly specify them all. But as you say, consistency is the most important thing here. > I find the extra ); on its own line offensive and unnatural, > just as clear, and much easier on the eye to write > > C : in Data); ...which I find uglier. But I'm probably in the minority there. > In GNAT we prefer to put things on a single line: > > > procedure Foo (D : in out Data; C : Data); > > If they fit comfortably on one line, and use the form with > one line per parameter only if that is not the case. In most places I've worked that is preferred too, if it is only one (or no) parameter. Any more than that, and it ends up being a personal judgement call which IMHO gives too much leeway to sloppier coders. Also, a multiple parameter procedure seems to be much more likely to have an extra parameter or two added later. Its annoying to have to radicaly reformat 4 lines of code from one because you added one parameter. (sigh) I guess any "example" he gave was doomed to start a long thread. :-) -- T.E.D. http://www.telepath.com/~dennison/Ted/TED.html Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: ada writing guide 2000-04-12 0:00 ` Ted Dennison 2000-04-12 0:00 ` Robert Dewar @ 2000-04-13 0:00 ` Riyaz Mansoor 2000-04-13 0:00 ` Ted Dennison 2000-04-13 0:00 ` David C. Hoos, Sr. 1 sibling, 2 replies; 76+ messages in thread From: Riyaz Mansoor @ 2000-04-13 0:00 UTC (permalink / raw) link does not seem to be working ted. "Ted Dennison" <dennison@telepath.com> wrote in message news:8d1vhj$hdr$1@nnrp1.deja.com... > In article <8d1rso$bir$2@bunyip.cc.uq.edu.au>, > "Riyaz Mansoor" <s800032@student.uq.edu.au> wrote: > > > > i was wondering where i can get/find ada code conventions? i know C > > has a standard. > > Try the Ada Quality and Style Guide, at > http://wuarchive.wustl.edu/languages/ada/ajpo/docs/style-guide/95style/h > tml/cover.html > > It is mean to be tailored to match site-specific guidlines, but it still > should give you a good idea of what is typical usage. > > > like for example what is the "standard" way to write a procedure > > declaration. > > > > procedure (D : in out Data; C : in Cata); > > procedure > > (D : in out Data; > > C : in Cata); > > You forgot the procedure's name. ;-) I prefer: > procedure Foo > (D : in out Data; > C : in Data > ); > > but some prefer > procedure Foo (D : in out Data; > C : in Data); > > I prefer the former because the parameters start in a standard place, > and won't get squeezed for space if the procedure name is long. Also, > its easier to see that the parens match. It does use up more vertical > real-estate, though (in this case, twice as much). > > -- > T.E.D. > > http://www.telepath.com/~dennison/Ted/TED.html > > > Sent via Deja.com http://www.deja.com/ > Before you buy. ^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: ada writing guide 2000-04-13 0:00 ` Riyaz Mansoor @ 2000-04-13 0:00 ` Ted Dennison 2000-04-13 0:00 ` David C. Hoos, Sr. 1 sibling, 0 replies; 76+ messages in thread From: Ted Dennison @ 2000-04-13 0:00 UTC (permalink / raw) In article <8d41os$3jn$1@bunyip.cc.uq.edu.au>, "Riyaz Mansoor" <s800032@student.uq.edu.au> wrote: > > link does not seem to be working ted. > > "Ted Dennison" <dennison@telepath.com> wrote in message > news:8d1vhj$hdr$1@nnrp1.deja.com... > > Try the Ada Quality and Style Guide, at > > http://wuarchive.wustl.edu/languages/ada/ajpo/docs/style-guide/95style/h > > tml/cover.html > > That's funny. I pasted the above into my browser and realoaded it. It loaded right away. Sometimes wuarchive can be a bit slow though. You did use the *entire* URL, right? I notice that your browser split it into two lines when you replied. You need both parts. Also, I'm a lot closer to Washington University (St. Louis) here in Oklahoma than you are over in Austrailia. :-) Can you get to the main page at http://wuarchive.wustl.edu/ ? wuarchive is one of the main (perhaps even *the* main) software repositories on the web. I'd definitely want access if I were you. -- T.E.D. http://www.telepath.com/~dennison/Ted/TED.html Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: ada writing guide 2000-04-13 0:00 ` Riyaz Mansoor 2000-04-13 0:00 ` Ted Dennison @ 2000-04-13 0:00 ` David C. Hoos, Sr. 1 sibling, 0 replies; 76+ messages in thread From: David C. Hoos, Sr. @ 2000-04-13 0:00 UTC (permalink / raw) Riyaz Mansoor <s800032@student.uq.edu.au> wrote in message news:8d41os$3jn$1@bunyip.cc.uq.edu.au... > > link does not seem to be working ted. > Here is a link that is working: http://www.adaic.org/docs/style-guide/95style/ The above directory has the document in several formats. <snip> ^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: ada writing guide 2000-04-12 0:00 ada writing guide Riyaz Mansoor 2000-04-12 0:00 ` Ted Dennison @ 2000-04-12 0:00 ` Robert Dewar 2000-04-13 0:00 ` Riyaz Mansoor 2000-04-14 0:00 ` Riyaz Mansoor 2 siblings, 1 reply; 76+ messages in thread From: Robert Dewar @ 2000-04-12 0:00 UTC (permalink / raw) In article <8d1rso$bir$2@bunyip.cc.uq.edu.au>, "Riyaz Mansoor" <s800032@student.uq.edu.au> wrote: > > i know C has a standard. I don't know this. Can you say clearly what you are referring to in the above statement. Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: ada writing guide 2000-04-12 0:00 ` Robert Dewar @ 2000-04-13 0:00 ` Riyaz Mansoor 2000-04-13 0:00 ` Jean-Marc Bourguet 2000-04-15 0:00 ` Robert Dewar 0 siblings, 2 replies; 76+ messages in thread From: Riyaz Mansoor @ 2000-04-13 0:00 UTC (permalink / raw) > > i know C has a standard. > > I don't know this. > > Can you say clearly what you are referring to in the above > statement. hehe ok so it was stupid. but u know what i mean. riyaz ^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: ada writing guide 2000-04-13 0:00 ` Riyaz Mansoor @ 2000-04-13 0:00 ` Jean-Marc Bourguet 2000-04-15 0:00 ` Robert Dewar 1 sibling, 0 replies; 76+ messages in thread From: Jean-Marc Bourguet @ 2000-04-13 0:00 UTC (permalink / raw) In article <8d41ki$c3f$1@bunyip.cc.uq.edu.au>, "Riyaz Mansoor" <s800032@student.uq.edu.au> wrote: > > > > > i know C has a standard. > > > > I don't know this. > > > > Can you say clearly what you are referring to in the above > > statement. > > hehe > > ok so it was stupid. but u know what i mean. I do not know. Emacs comes with something like 10 different indentation styles for C, and allows quite a lot of customization from these starting points. -- Jean-Marc Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: ada writing guide 2000-04-13 0:00 ` Riyaz Mansoor 2000-04-13 0:00 ` Jean-Marc Bourguet @ 2000-04-15 0:00 ` Robert Dewar 1 sibling, 0 replies; 76+ messages in thread From: Robert Dewar @ 2000-04-15 0:00 UTC (permalink / raw) In article <8d41ki$c3f$1@bunyip.cc.uq.edu.au>, "Riyaz Mansoor" <s800032@student.uq.edu.au> wrote: > > > > > i know C has a standard. > > > > I don't know this. > > > > Can you say clearly what you are referring to in the above > > statement. > > hehe > > ok so it was stupid. but u know what i mean. Not at all, I have no idea what you mean. There is absolutely NO standard for C layout conventions, so please explain, "hehe" is not very helpful. Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: ada writing guide 2000-04-12 0:00 ada writing guide Riyaz Mansoor 2000-04-12 0:00 ` Ted Dennison 2000-04-12 0:00 ` Robert Dewar @ 2000-04-14 0:00 ` Riyaz Mansoor 2000-04-14 0:00 ` Ted Dennison ` (4 more replies) 2 siblings, 5 replies; 76+ messages in thread From: Riyaz Mansoor @ 2000-04-14 0:00 UTC (permalink / raw) after reading a whole lot of replies (thanx) i have come to the understanding that ADA does not have strict code writing standard such as the ANSI C standard. nobody has mentioned any standard for ADA code writing. just different formats that different people use. of course i may be wrong. so is there a standard? riyaz ps: somebody replied something about this, but i had to ask. ^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: ada writing guide 2000-04-14 0:00 ` Riyaz Mansoor @ 2000-04-14 0:00 ` Ted Dennison 2000-04-14 0:00 ` Marin D. Condic 2000-04-14 0:00 ` tmoran ` (3 subsequent siblings) 4 siblings, 1 reply; 76+ messages in thread From: Ted Dennison @ 2000-04-14 0:00 UTC (permalink / raw) In article <8d6jfu$f6b$1@bunyip.cc.uq.edu.au>, "Riyaz Mansoor" <s800032@student.uq.edu.au> wrote: > > after reading a whole lot of replies (thanx) i have come to the > understanding that ADA does not have strict code writing standard such > as the ANSI C standard. nobody has mentioned any standard for ADA code > writing. just different formats that different people use. I'm curious exactly what this "strict code writing standard" for C you keep referring to is. There's "Hungarian notation", but that's not universally adhered to, and usually not rigidly when it is. And that just addresses identifier naming, not indentation. For instance, my vxWorks system uses at least 3 different naming styles for the C OS calls. Contrast that to the Ada world, where the issue of naming is really all-but decided (see the AQ&SG for an explanation). In fact, vxWorks even has some code that doesn't adhere to the convention of using ".h" for included files! If anything, I think you'll find that Ada code from different professionals looks much more similar that C code. There are some nitty disagreements, as this thread shows. But the small scope of those just shows how broad the agreement in the Ada community really is. The style guide I pointed to will clue you in on the basics of this style. -- T.E.D. http://www.telepath.com/~dennison/Ted/TED.html Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: ada writing guide 2000-04-14 0:00 ` Ted Dennison @ 2000-04-14 0:00 ` Marin D. Condic 0 siblings, 0 replies; 76+ messages in thread From: Marin D. Condic @ 2000-04-14 0:00 UTC (permalink / raw) Ted Dennison wrote: > If anything, I think you'll find that Ada code from different > professionals looks much more similar that C code. There are some nitty > disagreements, as this thread shows. But the small scope of those just > shows how broad the agreement in the Ada community really is. The style > guide I pointed to will clue you in on the basics of this style. > The ARM itself kind of implies some style. Most people code similar to what you see there. I've seen the Ada Quality and Style guide several years back and adopted a lot from that. Again, most Ada code I've seen follows that to some extent - at least in the more professional examples. (Then you see stuff that was clearly written by C programmers who were trying to make Ada look like C. :-) Naming conventions and such quite often change with problem domains, so its more important to stay consistent within the project rather than impose something across the board. If there is a C/C++ "Style" anywhere, I can say that I've seen lots of code that had no signs of consistent style at all - so it must not be very well adhered to. MDC -- ====================================================================== Marin David Condic - Quadrus Corporation - http://www.quadruscorp.com/ Send Replies To: m c o n d i c @ q u a d r u s c o r p . c o m Visit my web site at: http://www.mcondic.com/ "I'd trade it all for just a little more" -- Charles Montgomery Burns, [4F10] ====================================================================== ^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: ada writing guide 2000-04-14 0:00 ` Riyaz Mansoor 2000-04-14 0:00 ` Ted Dennison @ 2000-04-14 0:00 ` tmoran 2000-04-14 0:00 ` David C. Hoos, Sr. 2000-04-14 0:00 ` Robert A Duff ` (2 subsequent siblings) 4 siblings, 1 reply; 76+ messages in thread From: tmoran @ 2000-04-14 0:00 UTC (permalink / raw) >understanding that ADA does not have strict code writing standard such as >the ANSI C standard. nobody has mentioned any standard for ADA code writing. Do you mean preferred style, or language definition? The answers people have posted to your question have assumed you meant style, but of course there is no strict style standard for C (if you know of one, please tell us), so perhaps you meant language definition. If so, what you want is the Ada Language Reference Manual (LRM). Look for a link to it at www.adapower.com ^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: ada writing guide 2000-04-14 0:00 ` tmoran @ 2000-04-14 0:00 ` David C. Hoos, Sr. 2000-04-15 0:00 ` tmoran ` (2 more replies) 0 siblings, 3 replies; 76+ messages in thread From: David C. Hoos, Sr. @ 2000-04-14 0:00 UTC (permalink / raw) <tmoran@bix.com> wrote in message news:%wJJ4.740$%Y3.249597@news.pacbell.net... > >understanding that ADA does not have strict code writing standard such as > >the ANSI C standard. nobody has mentioned any standard for ADA code writing. > Do you mean preferred style, or language definition? The answers > people have posted to your question have assumed you meant style, but > of course there is no strict style standard for C (if you know of one, > please tell us), so perhaps you meant language definition. If so, > what you want is the Ada Language Reference Manual (LRM). Look for a > link to it at www.adapower.com Have you ever looked at http://www.delorie.com/gnu/docs/GNU/standards_toc.html This provides a coding stabndard for C, which could be considered "strict." ^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: ada writing guide 2000-04-14 0:00 ` David C. Hoos, Sr. @ 2000-04-15 0:00 ` tmoran 2000-04-17 0:00 ` Marc A. Criley 2000-04-15 0:00 ` Robert Dewar 2000-04-17 0:00 ` Ted Dennison 2 siblings, 1 reply; 76+ messages in thread From: tmoran @ 2000-04-15 0:00 UTC (permalink / raw) > http://www.delorie.com/gnu/docs/GNU/standards_toc.html > > This provides a coding stabndard for C, which could be considered "strict." It's hard to know what to say. A document dated 1999 that gives a standard for C and cautions against using any other language, including C++. A document whose "C style" part is all of 550 lines, or ten pages, in length, whereas "Ada Quality and Style" manages somehow to take 270 pages. A "strict" standard for the "C" language with statements like: "Please use formfeed characters (control-L) to divide the program into pages" "Insert extra parentheses so that Emacs will indent the code properly." "We find it easier to read a program when it has spaces before the operator, not after one. Here is the right way:" "Please put two spaces after the end of a sentence in your comments, so that the Emacs sentence commands will work." "Please write the comments in a GNU program in English, because English is the one language that nearly all programmers in all countries can read." I guess the adjective "strict" does apply in cases like: "It is important to put the open-brace that starts the body of a C function in column zero, and avoid putting any other open-brace or open-parenthesis or open-bracket in column zero. Several tools look for open-braces in column zero to find the beginnings of C functions. These tools will not work on code not formatted that way. It is also important for function definitions to start the name of the function in column zero. This helps people to search for function definitions, and may also help certain tools recognize them." I prefer Ada, and even if I was coding in GNU C, I'd read Ada Quality and Style for ideas. ^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: ada writing guide 2000-04-15 0:00 ` tmoran @ 2000-04-17 0:00 ` Marc A. Criley 0 siblings, 0 replies; 76+ messages in thread From: Marc A. Criley @ 2000-04-17 0:00 UTC (permalink / raw) tmoran@bix.com wrote: <snip> > > I prefer Ada, and even if I was coding in GNU C, I'd read Ada Quality > and Style for ideas. I saw to it that some of the AQ&S Guidelines on exception use were worked into the C++ coding standards for the project to which I'm assigned. Marc A. Criley Software Architect Lockheed Martin M&DS ^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: ada writing guide 2000-04-14 0:00 ` David C. Hoos, Sr. 2000-04-15 0:00 ` tmoran @ 2000-04-15 0:00 ` Robert Dewar 2000-04-17 0:00 ` Ted Dennison 2 siblings, 0 replies; 76+ messages in thread From: Robert Dewar @ 2000-04-15 0:00 UTC (permalink / raw) In article <8d82lq$4fp$1@hobbes2.crc.com>, "David C. Hoos, Sr." <david.c.hoos.sr@ada95.com> wrote: > http://www.delorie.com/gnu/docs/GNU/standards_toc.html > > This provides a coding stabndard for C, which could be considered "strict." The most important word here is "a" as in "a" coding standard. That's the point, there are of course lots of local standards for writing code in any language (any big COBOL shop for example will have a detailed document specifying coding standards, and many Ada shops certainly have such documents [ACT certainly has a fairly comprehensive document of this type]. Yes, and of course such documents exist in C shops, the GNU project does indeed attempt (fairly successfully) to enforce a single consistent style. But this is a very different from having "the" standard coding style. Languages of course differ in their approach. Some languages try to leave little lattitude (e.g. in COBOL, the margins for entering text are fixed, and identifier casing is fixed etc). Most recent languages have completely free form syntax. Freedom is good and bad in this context, good because it does not mandate choices that are really not a necessary part of the standard, bad because it leads to inconsistencies. The Ada standard tried to steer a compromise course, of leaving freedom, but implying preferred choices. Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: ada writing guide 2000-04-14 0:00 ` David C. Hoos, Sr. 2000-04-15 0:00 ` tmoran 2000-04-15 0:00 ` Robert Dewar @ 2000-04-17 0:00 ` Ted Dennison 2000-04-18 0:00 ` Geoff Bull 2 siblings, 1 reply; 76+ messages in thread From: Ted Dennison @ 2000-04-17 0:00 UTC (permalink / raw) In article <8d82lq$4fp$1@hobbes2.crc.com>, "David C. Hoos, Sr." <david.c.hoos.sr@ada95.com> wrote: > > <tmoran@bix.com> wrote in message > news:%wJJ4.740$%Y3.249597@news.pacbell.net... > > >understanding that ADA does not have strict code writing standard such as > > >the ANSI C standard. nobody has mentioned any standard for ADA code > writing. > > Do you mean preferred style, or language definition? The answers > > people have posted to your question have assumed you meant style, but > > of course there is no strict style standard for C (if you know of one, > > please tell us), so perhaps you meant language definition. If so, > > what you want is the Ada Language Reference Manual (LRM). Look for a > > link to it at www.adapower.com > > Have you ever looked at > http://www.delorie.com/gnu/docs/GNU/standards_toc.html > > This provides a coding stabndard for C, which could be considered "strict." > > Perhaps. But I'm hard-pressed to come up with any C program I've ever looked at that conforms to the following statement: Please use underscores to separate words in a name, so that the Emacs word commands can be useful within them. Stick to lower case; reserve upper case for macros and enum constants, and for name-prefixes that follow a uniform convention. This is completely antithetical to the "hungarian" notation that I find most commonly. The style used for old K&R C source ususally avoids underscores as well. -- T.E.D. http://www.telepath.com/~dennison/Ted/TED.html Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: ada writing guide 2000-04-17 0:00 ` Ted Dennison @ 2000-04-18 0:00 ` Geoff Bull 0 siblings, 0 replies; 76+ messages in thread From: Geoff Bull @ 2000-04-18 0:00 UTC (permalink / raw) Ted Dennison wrote: > Perhaps. But I'm hard-pressed to come up with any C program I've ever > looked at that conforms to the following statement: > > Please use underscores to separate words in a name, so that the Emacs > word commands can be useful within them. Stick to > lower case; reserve upper case for macros and enum constants, and for > name-prefixes that follow a uniform convention. This is a common convention, and a good one, I think. Here's an example for you (easy to find, it's from gnat!): if (size + MSIZE_ACCURACY >= available_memory) check_available_memory (size + MSIZE_ACCURACY); > This is completely antithetical to the "hungarian" notation that I find > most commonly. Yes it is, and hungarian notation is horrible! ^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: ada writing guide 2000-04-14 0:00 ` Riyaz Mansoor 2000-04-14 0:00 ` Ted Dennison 2000-04-14 0:00 ` tmoran @ 2000-04-14 0:00 ` Robert A Duff 2000-04-15 0:00 ` Robert Dewar 2000-04-15 0:00 ` Robert Dewar 4 siblings, 0 replies; 76+ messages in thread From: Robert A Duff @ 2000-04-14 0:00 UTC (permalink / raw) "Riyaz Mansoor" <s800032@student.uq.edu.au> writes: > after reading a whole lot of replies (thanx) i have come to the > understanding that ADA does not have strict code writing standard such as > the ANSI C standard. nobody has mentioned any standard for ADA code writing. > just different formats that different people use. There is a huge variety of styles used in C code. At least as much as in Ada. > of course i may be wrong. so is there a standard? The Ada RM defines a recommended indentation style, which most folks follow. Also a recommended capitalization style for identifiers and keywords. But it leaves open certain issues, such as what if things don't fit on a line, where should the line breaks go. - Bob ^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: ada writing guide 2000-04-14 0:00 ` Riyaz Mansoor ` (2 preceding siblings ...) 2000-04-14 0:00 ` Robert A Duff @ 2000-04-15 0:00 ` Robert Dewar 2000-04-15 0:00 ` Marin D. Condic 2000-04-15 0:00 ` Robert Dewar 4 siblings, 1 reply; 76+ messages in thread From: Robert Dewar @ 2000-04-15 0:00 UTC (permalink / raw) In article <8d6jfu$f6b$1@bunyip.cc.uq.edu.au>, "Riyaz Mansoor" <s800032@student.uq.edu.au> wrote: > > after reading a whole lot of replies (thanx) i have come to the > understanding that ADA does not have strict code writing standard such as > the ANSI C standard. nobody has mentioned any standard for ADA code writing. > just different formats that different people use. Actually, there IS a big difference in the standards here. Unlike the C standard, the Ada standard may not mandate a layout standard, but it does strongly suggest one. How? By laying out the syntax rules in the recommended style. Consequently, the basic layout in Ada is typically far more consistent than in C, since people generally follow the RM for Ada layout. There is also a fairly official document called Ada Quality and Style. Fairly official means that it was generated with a general consensus process, and published as one of the Ada project documents. OK, it is not an official standard, but many people follow the recommendations in this document. As far as I know there is no comparable document for C. Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: ada writing guide 2000-04-15 0:00 ` Robert Dewar @ 2000-04-15 0:00 ` Marin D. Condic 2000-04-15 0:00 ` Ken Garlington 2000-04-16 0:00 ` Ehud Lamm 0 siblings, 2 replies; 76+ messages in thread From: Marin D. Condic @ 2000-04-15 0:00 UTC (permalink / raw) Robert Dewar wrote: > There is also a fairly official document called > Ada Quality and Style. Fairly official means that it I seem to recall this document being on-line somewhere. I know I read the paper copy at one time because it was available to us as part of the Software Productivity Consortium. But is there an on-line source? MDC -- ====================================================================== Marin David Condic - Quadrus Corporation - http://www.quadruscorp.com/ Send Replies To: m c o n d i c @ q u a d r u s c o r p . c o m Visit my web site at: http://www.mcondic.com/ "I'd trade it all for just a little more" -- Charles Montgomery Burns, [4F10] ====================================================================== ^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: ada writing guide 2000-04-15 0:00 ` Marin D. Condic @ 2000-04-15 0:00 ` Ken Garlington 2000-04-27 0:00 ` gbull 2000-04-16 0:00 ` Ehud Lamm 1 sibling, 1 reply; 76+ messages in thread From: Ken Garlington @ 2000-04-15 0:00 UTC (permalink / raw) Ada Quality and Style is available at http://wuarchive.wustl.edu/languages/ada/ajpo/docs/style-guide/95style/html/ cover.html Allow me also to plug the just-released ISO/IEC TR 15942:2000(E), Information Technology - Programming languages - Guide for the use of the Ada programming language in high integrity systems. It's not on-line, unfortunately, but you can order it from http://www.iec.ch ^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: ada writing guide 2000-04-15 0:00 ` Ken Garlington @ 2000-04-27 0:00 ` gbull 0 siblings, 0 replies; 76+ messages in thread From: gbull @ 2000-04-27 0:00 UTC (permalink / raw) Everything under the http://wuarchive.wustl.edu/languages/ada/ajpo directory seems to have disappeared as of 2000-04-18. ftp://ftp.freesoftware.com/pub/languages/ada/ajpo/ is empty too! I found it at: ftp://ftp.freesoftware.com/pub/ase/ase01_06/docs/95style/html/cover.html In article <8d0K4.25407$hh2.693734@news.flash.net>, "Ken Garlington" <Ken.Garlington@computer.org> wrote: > Ada Quality and Style is available at > http://wuarchive.wustl.edu/languages/ada/ajpo/docs/style-guide/95style/h tml/ > cover.html > > Allow me also to plug the just-released > > ISO/IEC TR 15942:2000(E), Information Technology - Programming languages - > Guide for the use of the Ada programming language in high integrity systems. > > It's not on-line, unfortunately, but you can order it from http://www.iec.ch > > Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: ada writing guide 2000-04-15 0:00 ` Marin D. Condic 2000-04-15 0:00 ` Ken Garlington @ 2000-04-16 0:00 ` Ehud Lamm 1 sibling, 0 replies; 76+ messages in thread From: Ehud Lamm @ 2000-04-16 0:00 UTC (permalink / raw) Hi My SE Links page (down from my home page, see sig) points to the Ada Style Guide, and other places that may interest you. (The direct link is: http://wuarchive.wustl.edu/languages/ada/ajpo/docs/style-guide/ 95style/html/cover.html) Ehud Lamm mslamm@mscc.huji.ac.il http://purl.oclc.org/NET/ehudlamm <== My home on the web Check it out and subscribe to the E-List- for interesting essays and more! ^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: ada writing guide 2000-04-14 0:00 ` Riyaz Mansoor ` (3 preceding siblings ...) 2000-04-15 0:00 ` Robert Dewar @ 2000-04-15 0:00 ` Robert Dewar 4 siblings, 0 replies; 76+ messages in thread From: Robert Dewar @ 2000-04-15 0:00 UTC (permalink / raw) In article <8d6jfu$f6b$1@bunyip.cc.uq.edu.au>, "Riyaz Mansoor" <s800032@student.uq.edu.au> wrote: > > after reading a whole lot of replies (thanx) i have come to the > understanding that ADA does not have strict code writing standard such as > the ANSI C standard. nobody has mentioned any standard for ADA code writing. > just different formats that different people use. Clearly you have never read either standard. The claim that ANSI C has a strict code writing standard is one of the more amusing fantasy's to appear on this newsgroup in some time :-) My guess is that you have mistaken some local coding convention for C with the ANSI standard, which is quite a confusion! Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 76+ messages in thread
end of thread, other threads:[~2000-04-27 0:00 UTC | newest] Thread overview: 76+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2000-04-12 0:00 ada writing guide Riyaz Mansoor 2000-04-12 0:00 ` Ted Dennison 2000-04-12 0:00 ` Robert Dewar 2000-04-13 0:00 ` Jeffrey D. Cherry 2000-04-13 0:00 ` Ted Dennison 2000-04-13 0:00 ` Jeffrey D. Cherry 2000-04-13 0:00 ` Ted Dennison 2000-04-14 0:00 ` Pascal Obry 2000-04-14 0:00 ` Ted Dennison 2000-04-14 0:00 ` Pascal Obry 2000-04-17 0:00 ` Ted Dennison 2000-04-17 0:00 ` Florian Weimer 2000-04-17 0:00 ` Ted Dennison 2000-04-17 0:00 ` Ted Dennison 2000-04-18 0:00 ` Robert Dewar 2000-04-18 0:00 ` Ted Dennison 2000-04-18 0:00 ` Robert Dewar 2000-04-18 0:00 ` Ted Dennison 2000-04-18 0:00 ` Brian Courtney 2000-04-19 0:00 ` Florian Weimer 2000-04-19 0:00 ` Brian Courtney 2000-04-19 0:00 ` Florian Weimer 2000-04-19 0:00 ` Ted Dennison 2000-04-24 0:00 ` Samuel T. Harris 2000-04-19 0:00 ` Robert Dewar 2000-04-20 0:00 ` Ted Dennison 2000-04-20 0:00 ` Florian Weimer 2000-04-20 0:00 ` Ted Dennison 2000-04-24 0:00 ` Samuel T. Harris 2000-04-24 0:00 ` Robert A Duff 2000-04-25 0:00 ` Robert Dewar 2000-04-27 0:00 ` Samuel T. Harris 2000-04-20 0:00 ` Samuel T. Harris 2000-04-20 0:00 ` Ted Dennison 2000-04-21 0:00 ` Robert Dewar [not found] ` <38FFd43e.70f1bb7d@telepath.com> 2000-04-21 0:00 ` Larry Kilgallen 2000-04-21 0:00 ` Ted Dennison 2000-04-21 0:00 ` Robert Dewar 2000-04-24 0:00 ` Samuel T. Harris 2000-04-24 0:00 ` Robert A Duff 2000-04-27 0:00 ` Samuel T. Harris 2000-04-20 0:00 ` Emmanuel Briot 2000-04-20 0:00 ` Ted Dennison 2000-04-13 0:00 ` Robert A Duff 2000-04-16 0:00 ` Simon Wright 2000-04-16 0:00 ` Robert Dewar 2000-04-13 0:00 ` Ray Blaak 2000-04-15 0:00 ` Robert Dewar 2000-04-16 0:00 ` Simon Wright 2000-04-13 0:00 ` Samuel T. Harris 2000-04-13 0:00 ` Paul Graham 2000-04-13 0:00 ` Ted Dennison 2000-04-13 0:00 ` Riyaz Mansoor 2000-04-13 0:00 ` Ted Dennison 2000-04-13 0:00 ` David C. Hoos, Sr. 2000-04-12 0:00 ` Robert Dewar 2000-04-13 0:00 ` Riyaz Mansoor 2000-04-13 0:00 ` Jean-Marc Bourguet 2000-04-15 0:00 ` Robert Dewar 2000-04-14 0:00 ` Riyaz Mansoor 2000-04-14 0:00 ` Ted Dennison 2000-04-14 0:00 ` Marin D. Condic 2000-04-14 0:00 ` tmoran 2000-04-14 0:00 ` David C. Hoos, Sr. 2000-04-15 0:00 ` tmoran 2000-04-17 0:00 ` Marc A. Criley 2000-04-15 0:00 ` Robert Dewar 2000-04-17 0:00 ` Ted Dennison 2000-04-18 0:00 ` Geoff Bull 2000-04-14 0:00 ` Robert A Duff 2000-04-15 0:00 ` Robert Dewar 2000-04-15 0:00 ` Marin D. Condic 2000-04-15 0:00 ` Ken Garlington 2000-04-27 0:00 ` gbull 2000-04-16 0:00 ` Ehud Lamm 2000-04-15 0:00 ` Robert Dewar
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox