* Code Formatters @ 1996-10-28 0:00 Dave Smith 1996-10-29 0:00 ` Frank C. Post 1996-11-01 0:00 ` Mike Stark 0 siblings, 2 replies; 21+ messages in thread From: Dave Smith @ 1996-10-28 0:00 UTC (permalink / raw) I know it`s an old old question but are there any decent code formatters for Ada. I`m aware of Ada Assured from a company called Grammatech, anyone out there have any experience of it? I personally can't stand code formatters as a matter of principal, they just make coders lazy. Anyway, if anyone has any views, let me know. Many Thanks Dave Smith Chief Software Engineer GMCS ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Code Formatters 1996-10-28 0:00 Code Formatters Dave Smith @ 1996-10-29 0:00 ` Frank C. Post 1996-11-01 0:00 ` Mike Stark 1 sibling, 0 replies; 21+ messages in thread From: Frank C. Post @ 1996-10-29 0:00 UTC (permalink / raw) We had Meridian's Ada compiler for a long time, and it came packaged with AdaForm. However, I'm sure that the formatter was not dependant upon the Meridian environment. It was an ok product whcih had a decent selection of switches that could be used to control indentation, capitalization, etc. Maybe Meridian (or Alsys or Thomson) has it available as standalone. --postman ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Code Formatters 1996-10-28 0:00 Code Formatters Dave Smith 1996-10-29 0:00 ` Frank C. Post @ 1996-11-01 0:00 ` Mike Stark 1996-11-04 0:00 ` Robert Dewar ` (5 more replies) 1 sibling, 6 replies; 21+ messages in thread From: Mike Stark @ 1996-11-01 0:00 UTC (permalink / raw) Dave Smith wrote: > > I know it`s an old old question but are there any decent > code formatters for Ada. I`m aware of Ada Assured from > a company called Grammatech, anyone out there have any > experience of it? > > I personally can't stand code formatters as a matter of > principal, they just make coders lazy. I completely disagree -- we shouldn't be paying software developers to worry about whether the indentation is two or three spaces, or whether the "record" keyword should be on the same line or the next line as the "type" keyword. We're paying people to think, not to format. > > Anyway, if anyone has any views, let me know. > I think I just did! :) Mike > Many Thanks > > Dave Smith > Chief Software Engineer > GMCS ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Code Formatters 1996-11-01 0:00 ` Mike Stark @ 1996-11-04 0:00 ` Robert Dewar 1996-11-05 0:00 ` Philip Brashear 1996-11-05 0:00 ` Ole-Hjalmar Kristensen FOU.TD/DELAB ` (4 subsequent siblings) 5 siblings, 1 reply; 21+ messages in thread From: Robert Dewar @ 1996-11-04 0:00 UTC (permalink / raw) Mike Stark says "I completely disagree -- we shouldn't be paying software developers to worry about whether the indentation is two or three spaces, or whether the "record" keyword should be on the same line or the next line as the "type" keyword. We're paying people to think, not to format." This is like saying that we shouldn't be paying novelists to write correct grammar or elegant style, they should just be thinking aout plots, and copy editors will fix things up. In fact the only kind of software engineers that I would be willing to pay are those who DO worry about the style of their code, and take some pride in laying it out and documenting it in an elegant manner. Thinking that automatic formatting programs can convert junk code to elegant code, particularly with respect to laying out comments nicely, is like those who in the 60's thought that they could replace docuemtnation by automatic flow chart generators. ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Code Formatters 1996-11-04 0:00 ` Robert Dewar @ 1996-11-05 0:00 ` Philip Brashear 1996-11-05 0:00 ` John English 0 siblings, 1 reply; 21+ messages in thread From: Philip Brashear @ 1996-11-05 0:00 UTC (permalink / raw) In article <dewar.847124036@merv>, Robert Dewar <dewar@merv.cs.nyu.edu> wrote: >In fact the only kind of software engineers that I would be willing to pay >are those who DO worry about the style of their code, and take some pride >in laying it out and documenting it in an elegant manner. Right on, Robert! That's why I drive my Ada students (at the University of Dayton) absolutely NUTS by talking so much about style, readability, etc. If the code is not reasonably formatted, then it's difficult to read, hence difficult to understand; hence difficult to get right (not to mention that minor activity called "maintenance")! Phil Brashear ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Code Formatters 1996-11-05 0:00 ` Philip Brashear @ 1996-11-05 0:00 ` John English 0 siblings, 0 replies; 21+ messages in thread From: John English @ 1996-11-05 0:00 UTC (permalink / raw) Philip Brashear (brashear@ns1.sw-eng.falls-church.va.us) wrote: : In article <dewar.847124036@merv>, Robert Dewar <dewar@merv.cs.nyu.edu> wrote: : >In fact the only kind of software engineers that I would be willing to pay : >are those who DO worry about the style of their code, and take some pride : >in laying it out and documenting it in an elegant manner. : Right on, Robert! : That's why I drive my Ada students (at the University of Dayton) absolutely : NUTS by talking so much about style, readability, etc. I always tell my students that the compiler is far more forgiving about layout than I am: "If I can't read it, I won't mark it". --------------------------------------------------------------- John English | mailto:je@brighton.ac.uk Senior Lecturer | http://www.comp.it.bton.ac.uk/je Dept. of Computing | fax: (+44) 1273 642405 University of Brighton | --------------------------------------------------------------- ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Code Formatters 1996-11-01 0:00 ` Mike Stark 1996-11-04 0:00 ` Robert Dewar @ 1996-11-05 0:00 ` Ole-Hjalmar Kristensen FOU.TD/DELAB 1996-11-05 0:00 ` Robert Dewar 1996-11-06 0:00 ` Mike Stark ` (3 subsequent siblings) 5 siblings, 1 reply; 21+ messages in thread From: Ole-Hjalmar Kristensen FOU.TD/DELAB @ 1996-11-05 0:00 UTC (permalink / raw) In article <dewar.847124036@merv> dewar@merv.cs.nyu.edu (Robert Dewar) writes: Mike Stark says "I completely disagree -- we shouldn't be paying software developers to worry about whether the indentation is two or three spaces, or whether the "record" keyword should be on the same line or the next line as the "type" keyword. We're paying people to think, not to format." This is like saying that we shouldn't be paying novelists to write correct grammar or elegant style, they should just be thinking aout plots, and copy editors will fix things up. Yes, I agree, but only to a certain extent. When you write a report, do you use hours fiddling with fonts, margins, etc. on a wysiwyg editor, or do you describe the structure of the document and let something like Tex/Latex take care of the details? Certainly, those tasks which can be done more efficiently by the computer should be done that way. In fact the only kind of software engineers that I would be willing to pay are those who DO worry about the style of their code, and take some pride in laying it out and documenting it in an elegant manner. Your idea of elegant code may not coincide with mine. As a project leader, I want *standardized* layout. Having a standard layout which is conformant to the output to some prettyprinter is in my opinion a good idea, because it means that those who do not want to be burdened with the detailed layout can avoid it. This does not stop anyone from documenting the program in an elegant manner, assuming that you can stop the prettyprinter from mangling your comments. In my experience, this is not much of a problem, unless you insist on very arcane commenting styles. Thinking that automatic formatting programs can convert junk code to elegant code, particularly with respect to laying out comments nicely, is like those who in the 60's thought that they could replace docuemtnation by automatic flow chart generators. We are not talking about converting junk code, but about avoiding unnecessary work which could be done by a program. ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Code Formatters 1996-11-05 0:00 ` Ole-Hjalmar Kristensen FOU.TD/DELAB @ 1996-11-05 0:00 ` Robert Dewar 1996-11-05 0:00 ` Larry Kilgallen 0 siblings, 1 reply; 21+ messages in thread From: Robert Dewar @ 1996-11-05 0:00 UTC (permalink / raw) Ole-Hjalmar says "Your idea of elegant code may not coincide with mine. As a project leader, I want *standardized* layout. Having a standard layout which is conformant to the output to some prettyprinter is in my opinion a good idea, because it means that those who do not want to be burdened with the detailed layout can avoid it. This does not stop anyone from documenting the program in an elegant manner, assuming that you can stop the prettyprinter from mangling your comments." I don't accept this attitude. It is important for a team working together on a product to agree on a concept of elegant style. Otherwise you get a situation where people do not like to work on other people's programs. Note that your model requires an unpretty printer, and that is much harder. Consider programmer A thinks the standard style is nuts, and does his or her own thing. The code that A generates is fed into a pretty printer to check into the configuration management system. Now, what does A do? Work with the checked in version, cerainly not, it's in unacceptable junk style, so they keep a mirror in what they consider "proper" style. Now here's where the problem comes in, programmer B wants to modify that same file. What do they do? Work on the checked in version? But now that means that programmer A refuses to work with the result! Work with the mirror? But that is in some (to them) horrible style. The model where everyone uses there own style leads to a notion of code ownership that is inimical to large projects. I worked in one large company (the name would amuse you, but should be kept private I think), where a critical component of the software was written in a private style with Mixed_Case_Identifiers_With_Some_ACRONYMS_In_Upper_Case. The company style was ALL_UPPER_CASE. Now you can pretty print the first into the second, but you cannot go backwards. The result was that this component was the private property of this one guy, and when he left, the code was an unknown mystery. This is not an uncommon situation. In the GNAT project, we take a totally different approach. We discuss style, and where there is a disagreement, we just vote, and take the simple majority input. There is some horse-trading in setting up the agreements, so that hopefully no one, at least no one who was originally, involved feels too left out. Then the minority changes. The change can be painful (as I have mentioned in the past, I found it hard to change from SHOUTING_IDENTIFIERS to Mixed_Case, but you get used to everything). Similarly people coming onto the project later often complain at first, but people adapt, and this adaptation is just something that we insist on. The result is an environment in which there is very little sense of code ownership, and anyone who knows how can modify any unit in the system (we have an elaborate regression testing scheme to make sure that people cannot introduce regressions as they do such modifications). This leads to a much more productive and cooperative environment, and, most importantly, there is almost no code that is understood by only one person. P.S. Sure, I have done a lot of COBOL programming, and you get used to any style. For example, in COBOL, even when writing non-typical COBOL code (I wrote a big chunk of the Realia COBOL compiler, now marketed by Computer Associates, and that compiler is 100% in COBOL), I adopted the COBOL style, and preferred IS GREATER THAN to >. As I say, style is really what you are used to. Another advantage of standardized style is that people throughout the Ada community can more easily read one another's code. There is nothing in C that stops you using the ALL_UPPER_CASE style for identifiers, but C programmers will find your programs (a) ugly and (b) hard to read. Similarly in Ada, there is nothing that stops you from using Mike Feldman's all upper case keyword style, but most Ada programmers will find the resulting programs (a) ugly and (b) hard to read. As for tools, yes, of course, it is useful to have tools to help with minor style issues, preferably ones that guide you as you do the original creation of the source, such as the Ada mode in EMACS. I personally prefer not to use any such tools, I am a fast typist and I find that any molestation of the source as I enter it slows me down, but many other peoplee, including some people on the GNAT team could not live without EMACS Ada mode. That's a personal choice. The critical thing is that everyone can read everyone elses code, and work with it easily, how that code is produced is not critical, but the idea of using code formatters to achieve this kind of interchange simply does not work. ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Code Formatters 1996-11-05 0:00 ` Robert Dewar @ 1996-11-05 0:00 ` Larry Kilgallen 1996-11-05 0:00 ` Robert Dewar 0 siblings, 1 reply; 21+ messages in thread From: Larry Kilgallen @ 1996-11-05 0:00 UTC (permalink / raw) In article <dewar.847201701@merv>, dewar@merv.cs.nyu.edu (Robert Dewar) writes: > In the GNAT project, we take a totally different approach. We discuss ^^^^^^^^^^^^^^^^^^^ > style, and where there is a disagreement, we just vote, and take the > simple majority input. Easy. > Another advantage of standardized style is that people throughout the ^^^^^^^^^^^^^^ > Ada community can more easily read one another's code. ^^^^^^^^^^^^^ Hard. Those who want to change the style of something they did not write are forced to provide a converter, but only when they provide it to another (such as by checking it in) can styles be enforced, such as by noticing that Channels_For_CBS _or_ Channels_For_CBs _both_ change to Channels_For_Cbs which does not match the original (in either case). Larry Kilgallen ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Code Formatters 1996-11-05 0:00 ` Larry Kilgallen @ 1996-11-05 0:00 ` Robert Dewar 1996-11-06 0:00 ` Dave Smith 0 siblings, 1 reply; 21+ messages in thread From: Robert Dewar @ 1996-11-05 0:00 UTC (permalink / raw) Larry said "> Another advantage of standardized style is that people throughout the ^^^^^^^^^^^^^^ > Ada community can more easily read one another's code. ^^^^^^^^^^^^^ Hard." Well, sure, hard in general, but at least for identifier capitalization, there is something approaching a consensus. \x1a ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Code Formatters 1996-11-05 0:00 ` Robert Dewar @ 1996-11-06 0:00 ` Dave Smith 1996-11-06 0:00 ` Larry Kilgallen 1996-11-06 0:00 ` Robert Dewar 0 siblings, 2 replies; 21+ messages in thread From: Dave Smith @ 1996-11-06 0:00 UTC (permalink / raw) As I seem to have started off a good old fashioned discussion on the rights and wrongs of standards formats, let me add another tw'pence worth. Surely what we need are decent development environments with good language sensitive editors. These should be able to read a file containing the "rules" to be used for layout, the indenting, capitalization, etc. being done as the code is typed in. Or maybe it would have been useful to have included the Ada Style Guide (the "bible" as far as I am concerned) as part of the ANSI standard. Them we would all have code that conformed to the same layout. To me, the reasons for having a standard layout are: 1) Coders don't need to think how to layout the code, and so can get on with the coding. 2) It's easier to read someone else`s code. 3) Having a standard layout makes it easier to give the code listings to the customer. The last thing I want to do is to send a customer the listings for ten packages all using a different style. BTW Thanks to Robert Dewar for getting involved in this thread... "We are not worthy!" Dave Smith Chief Software Engineer GEC-Marconi S3I Combat Systems Division Addlestone England ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Code Formatters 1996-11-06 0:00 ` Dave Smith @ 1996-11-06 0:00 ` Larry Kilgallen 1996-11-08 0:00 ` Robert Dewar 1996-11-06 0:00 ` Robert Dewar 1 sibling, 1 reply; 21+ messages in thread From: Larry Kilgallen @ 1996-11-06 0:00 UTC (permalink / raw) In article <55q621$v6s@gcsin3.geccs.gecm.com>, Dave Smith <david.h.smith@gecm.com> writes: > Surely what we need are decent development environments with > good language sensitive editors. These should be able to read > a file containing the "rules" to be used for layout, the indenting, > capitalization, etc. being done as the code is typed in. Another dimension is syntax coloring. If an editor can be set to do _only_ syntax coloring someone gets aid dealing with code but does not automatically disturb placement. BBEdit seems likely to get syntax coloring for Ada, which to me is actually more significant than the same for an editor provided with an Ada compiler, where one would expect such support. Also I would prefer editors from people devoted to editors as they will likely do a better job for cut and paste, etc. LSE on VMS of course has done Ada for years, although I do not use it because I have another favorite editor on VMS. DEC did Ada 83, of course, but those templates can be updated for Ada 95 by anyone who cares to do so. Larry Kilgallen ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Code Formatters 1996-11-06 0:00 ` Larry Kilgallen @ 1996-11-08 0:00 ` Robert Dewar 0 siblings, 0 replies; 21+ messages in thread From: Robert Dewar @ 1996-11-08 0:00 UTC (permalink / raw) Larry says "BBEdit seems likely to get syntax coloring for Ada, which to me is actually more significant than the same for an editor provided with an Ada compiler, where one would expect such support. Also I would prefer editors from people devoted to editors as they will likely do a better job for cut and paste, etc." Note of course that EMACS also provides Ada coloring mode, as well as lots of other helpful stuff. ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Code Formatters 1996-11-06 0:00 ` Dave Smith 1996-11-06 0:00 ` Larry Kilgallen @ 1996-11-06 0:00 ` Robert Dewar 1 sibling, 0 replies; 21+ messages in thread From: Robert Dewar @ 1996-11-06 0:00 UTC (permalink / raw) Dave Smith says "Or maybe it would have been useful to have included the Ada Style Guide (the "bible" as far as I am concerned) as part of the ANSI standard. Them we would all have code that conformed to the same layout." Dubious -- first, you could never have got agreement on a specific set of rules. Second, and perhaps more important, a good set of style guidelines is just that, a set of guidelines, not absoulute rules, and many of them are occasionally broken for good reasons. For example, in the GNAT world, we enforce the -gnatf set of rules, oops, I mean -gnatg, with the compiler considering violations to be errors (for details, have a look at style.adb i the GNAT sources). But the GNAT style involves MANY other rules that are not enforced mechanically (they are mostly enforced by self discipline, and then I check all checkins to make sure they meet the style rules, early on I used to find many deviations, now everyone really knows the rules and there is rarely need for correction, but that does not mean that these style reuls are oebyed 100% ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Code Formatters 1996-11-01 0:00 ` Mike Stark 1996-11-04 0:00 ` Robert Dewar 1996-11-05 0:00 ` Ole-Hjalmar Kristensen FOU.TD/DELAB @ 1996-11-06 0:00 ` Mike Stark 1996-11-07 0:00 ` Axel Boness ` (2 subsequent siblings) 5 siblings, 0 replies; 21+ messages in thread From: Mike Stark @ 1996-11-06 0:00 UTC (permalink / raw) Ole-Hjalmar Kristensen FOU.TD/DELAB wrote: > > In article <dewar.847124036@merv> dewar@merv.cs.nyu.edu (Robert Dewar) writes: > > Mike Stark says > > "I completely disagree -- we shouldn't be paying software developers to > worry about whether the indentation is two or three spaces, or whether > the "record" keyword should be on the same line or the next line as the > "type" keyword. We're paying people to think, not to format." > > This is like saying that we shouldn't be paying novelists to write correct > grammar or elegant style, they should just be thinking aout plots, and > copy editors will fix things up. No, Robert, what I am really saying is that a novelist shouldn't have to worry about page layout and fonts. I think by disagreeing "completely" I obscured the distinction (and there is one, in my IMHO) between "formatting" and "programming style". The former is an area that is properly left to tools (if you can find one that will do what you want -- at NASA we use acronyms heavily, so we like variable names such as "IRU_Measurement_Partials" instead of "Inertial_Reference_Unit_Partial_Derivatives"). Programming style of course, should be as Robert says -- correct and elegant. > > Yes, I agree, but only to a certain extent. When you write a report, > do you use hours fiddling with fonts, margins, etc. on a wysiwyg > editor, or do you describe the structure of the document and let > something like Tex/Latex take care of the details? Certainly, those > tasks which can be done more efficiently by the computer should be > done that way. > > In fact the only kind of software engineers that I would be willing to pay > are those who DO worry about the style of their code, and take some pride > in laying it out and documenting it in an elegant manner. I agree in the case of programming style. The problem on formatting is that there is more than one elegant manner, and projects want code to read consistently. This to me is where tools come in -- to give the delivered code a *consistent* style as well as an *elegant* one. > > Your idea of elegant code may not coincide with mine. As a project > leader, I want *standardized* layout. Having a standard layout > which is conformant to the output to some prettyprinter is in my > opinion a good idea, because it means that those who do not want to be > burdened with the detailed layout can avoid it. This does not stop > anyone from documenting the program in an elegant manner, assuming > that you can stop the prettyprinter from mangling your comments. In my > experience, this is not much of a problem, unless you insist on very > arcane commenting styles. > > Thinking that automatic formatting programs can convert junk code to > elegant code, particularly with respect to laying out comments nicely, > is like those who in the 60's thought that they could replace docuemtnation > by automatic flow chart generators. This is not at all what I was thinking. I don't really want to go beyond maintaining that we don't pay software developers to worry about whether standard indentation is two, three, or four characters. > > We are not talking about converting junk code, but about avoiding > unnecessary work which could be done by a program. Mike ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Code Formatters 1996-11-01 0:00 ` Mike Stark ` (2 preceding siblings ...) 1996-11-06 0:00 ` Mike Stark @ 1996-11-07 0:00 ` Axel Boness 1996-11-08 0:00 ` Robert Dewar 1996-11-09 0:00 ` Simon Wright 1996-11-12 0:00 ` Axel Boness 5 siblings, 1 reply; 21+ messages in thread From: Axel Boness @ 1996-11-07 0:00 UTC (permalink / raw) In article <dewar.847201701@merv>, dewar@merv.cs.nyu.edu (Robert Dewar) writes: |>Ole-Hjalmar says |> |>"Your idea of elegant code may not coincide with mine. As a project |>leader, I want *standardized* layout. Having a standard layout |>which is conformant to the output to some prettyprinter is in my |>opinion a good idea, because it means that those who do not want to be |>burdened with the detailed layout can avoid it. This does not stop |>anyone from documenting the program in an elegant manner, assuming |>that you can stop the prettyprinter from mangling your comments." |> I totally agree with you. Here we have thousands of units of code which were written (and maintened) by about 80 different developpers. Each had his own style of formatting. Readability is good because people took care when writting the code. But styles are different and when one is maintening the code he has to browse in different styles loosing time to understand how the code is formatted. Therefore I would like to work with a language where presentation is normalised (enforced by the editor) even if it's not as beautifull as it may be. ------------------------------------------------------------------- Axel Boness http://www.anywhere.com/standard_disclaimer.html Tel : (33) 4 76 41 46 00 (4811) Fax : (33) 4 76 41 47 47 E-Mail : Axel.Boness@Sema-Grenoble.fr ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Code Formatters 1996-11-07 0:00 ` Axel Boness @ 1996-11-08 0:00 ` Robert Dewar 0 siblings, 0 replies; 21+ messages in thread From: Robert Dewar @ 1996-11-08 0:00 UTC (permalink / raw) Axel says "Therefore I would like to work with a language where presentation is normalised (enforced by the editor) even if it's not as beautifull as it may be." Well that's a bit inconsistent, do you mean enforced by the language, as implied by your first phrase, or enforced by the tools you are using (in which case it has nothing to do with the language). For a *language* that enforces style, COBOL comes closest probably, but still leaves LOTS unsaid, and extensive coding standards are still needed. I know of no *language* so tightly defined as to make auxiliary style guidelines unnecessary. Whatever language you are using, you need to work in an environment where there are clear style rules that are consistently followed. There are many ways of enforcing such rules (threat of firing people, social pressure, job evaluation in genral, automatic editing tools, automatic formatting tools, checks in the compiler etc.) Of these, I prefer checks in the compiler (as we use in GNAT, with -gnatg) but these are seldome more than very simple issues. I personally don't like any editor that messes with me in any way (I hate templates or any kind of on the fly fixup of what I type), but others really like editors that help out (e.g. Ada mode in EMACS). ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Code Formatters 1996-11-01 0:00 ` Mike Stark ` (3 preceding siblings ...) 1996-11-07 0:00 ` Axel Boness @ 1996-11-09 0:00 ` Simon Wright 1996-11-12 0:00 ` Axel Boness 5 siblings, 0 replies; 21+ messages in thread From: Simon Wright @ 1996-11-09 0:00 UTC (permalink / raw) Dave Smith <david.h.smith@gecm.com> writes: > Surely what we need are decent development environments with > good language sensitive editors. These should be able to read > a file containing the "rules" to be used for layout, the indenting, > capitalization, etc. being done as the code is typed in. The old Rational Environment looked like this, to the user. I'm not sure if it was even possible to write eg Text_IO! I'm not familiar with APEX, perhaps it works similarly? Of course, any help is welcome (eg, emacs ada-mode). But I strongly agree with the person who wrote that the programmer who cares enough to get the surface details right is likely to care about the deeper aspects too. I tend to look at it the other way round; if he doesn't care what his work looks like, why should I suppose he cares about what it does? -- Simon Wright Work Email: simon.j.wright@gecm.com Ferranti Naval Systems Voice: +44(0)1705-701778 GEC-Marconi S3I Combat Systems Division FAX: +44(0)1705-701800 ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Code Formatters 1996-11-01 0:00 ` Mike Stark ` (4 preceding siblings ...) 1996-11-09 0:00 ` Simon Wright @ 1996-11-12 0:00 ` Axel Boness 5 siblings, 0 replies; 21+ messages in thread From: Axel Boness @ 1996-11-12 0:00 UTC (permalink / raw) In article <dewar.847456987@merv>, dewar@merv.cs.nyu.edu (Robert Dewar) writes: |>Axel says |> |>"Therefore I would like to work with a language where presentation is |>normalised (enforced by the editor) even if it's not as beautifull as |>it may be." I meant "enforced by the language". I deeply apologise not to have reread my posting before submitting it. It took me a lot of time to write the posting because english is not my mother tongue, and I didn't give myself time to reread (well I have to work from time to time :-). |>For a *language* that enforces style, COBOL comes closest probably, but |>still leaves LOTS unsaid, and extensive coding standards are still needed. |>I know of no *language* so tightly defined as to make auxiliary style |>guidelines unnecessary. There are two major kinds of rules: 1) presentation (I mean indentation, line size, relative position of keywords, ...) 2) programming style (choice of the identifier (size and meaning), volume of the comments, size of the subprograms...) Type 1) rule may be clearly expressed even if the result of applying these rules is not always good looking. There are always pathological cases. Type 2) rule are part of the programming activity and are personnal to each developper even if it's possible to give bounds with programming rules (like those in the Ada style guidebook). |>Of these, I prefer checks in the compiler (as we use in GNAT, with -gnatg) |>but these are seldome more than very simple issues. I personally don't |>like any editor that messes with me in any way (I hate templates or any |>kind of on the fly fixup of what I type), but others really like editors |>that help out (e.g. Ada mode in EMACS). I do have problems with such editors. But if it's the price to pay to have homogeneous code (I mean presentation), I'm willing to pay, if it's "universal". ------------------------------------------------------------------- Axel Boness http://www.anywhere.com/standard_disclaimer.html Tel : (33) 4 76 41 46 00 (4811) Fax : (33) 4 76 41 47 47 E-Mail : Axel.Boness@Sema-Grenoble.fr ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Code Formatters
@ 1996-11-05 0:00 Marin David Condic, 561.796.8997, M/S 731-93
0 siblings, 0 replies; 21+ messages in thread
From: Marin David Condic, 561.796.8997, M/S 731-93 @ 1996-11-05 0:00 UTC (permalink / raw)
Philip Brashear <brashear@NS1.SW-ENG.FALLS-CHURCH.VA.US> writes:
>If the code is not reasonably formatted, then it's difficult to read, hence
>difficult to understand; hence difficult to get right (not to mention that
>minor activity called "maintenance")!
>
This is all true, but there's another factor to consider. The
programmer who is obsessive-compulsive enough to go back over the
code, space everything properly, correct the character case of
everything, get the indenting right, etc. etc. is also going to be
the one who is double checking all the logic as well. Some of it
is by virtue of simply reviewing the code - you notice more
mistakes. Some of it is by individual mindset. If you're careful
enough to get the purely superficial things correct in every
detail, you are more likely to be the one agonizing over getting
all the fundamental things correct as well.
MDC
Marin David Condic, Senior Computer Engineer ATT: 561.796.8997
M/S 731-96 Technet: 796.8997
Pratt & Whitney, GESP Fax: 561.796.4669
P.O. Box 109600 Internet: CONDICMA@PWFL.COM
West Palm Beach, FL 33410-9600 Internet: CONDIC@FLINET.COM
===============================================================================
"Outside of a dog, a book is man's best friend; inside a dog,
it's too dark to read..."
-- Groucho Marx
===============================================================================
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Code Formatters @ 1996-11-14 0:00 Simon Johnston 0 siblings, 0 replies; 21+ messages in thread From: Simon Johnston @ 1996-11-14 0:00 UTC (permalink / raw) Robert Dewar wrote: [snip] > but these are seldome more than very simple issues. I personally don't > like any editor that messes with me in any way (I hate templates or = any > kind of on the fly fixup of what I type), but others really like = editors > that help out (e.g. Ada mode in EMACS). One of my biggest gripes about VisualBasic programming is that damn! = editor which moves my code around, refuses to allow me to use additional = spaces to line up code.=20 It does however enforce capitalization, a thorny issue in this group :) with StandardDisclaimer; use StandardDisclaimer; package Sig is --,----------------------------------------------------------------------= ---. --|Simon K. Johnston - Technical Architect (C++/Ada95) |ICL Retail = Systems | --|-----------------------------------------------------|St Martins = Place | --|Internet : skj@acm.org |51 Bath Road = | --|Telephone: +44 (0)1753 793600 Fax: +44 (0)1753 793636|Slough = | --|Internal : 7286 4617 OP Mail: S.K.Johnston@BRA0801 |Berkshire, SL1 = 3UG | --|WWW URL : http://www.acm.org/~skj/ |United Kingdom = | --`----------------------------------------------------------------------= ---' end Sig; ^ permalink raw reply [flat|nested] 21+ messages in thread
end of thread, other threads:[~1996-11-14 0:00 UTC | newest] Thread overview: 21+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 1996-10-28 0:00 Code Formatters Dave Smith 1996-10-29 0:00 ` Frank C. Post 1996-11-01 0:00 ` Mike Stark 1996-11-04 0:00 ` Robert Dewar 1996-11-05 0:00 ` Philip Brashear 1996-11-05 0:00 ` John English 1996-11-05 0:00 ` Ole-Hjalmar Kristensen FOU.TD/DELAB 1996-11-05 0:00 ` Robert Dewar 1996-11-05 0:00 ` Larry Kilgallen 1996-11-05 0:00 ` Robert Dewar 1996-11-06 0:00 ` Dave Smith 1996-11-06 0:00 ` Larry Kilgallen 1996-11-08 0:00 ` Robert Dewar 1996-11-06 0:00 ` Robert Dewar 1996-11-06 0:00 ` Mike Stark 1996-11-07 0:00 ` Axel Boness 1996-11-08 0:00 ` Robert Dewar 1996-11-09 0:00 ` Simon Wright 1996-11-12 0:00 ` Axel Boness -- strict thread matches above, loose matches on Subject: below -- 1996-11-05 0:00 Marin David Condic, 561.796.8997, M/S 731-93 1996-11-14 0:00 Simon Johnston
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox