All-Out Flamewar... (was good/bad OOPS)

Go away for a few days and you miss it all... A few opinions...

Programming is a craft more than an art (software engineering, not
black magic) and as such, is about writing code that works, first
and foremost. If it works well, even better. The same goes for
ease of maintenance, memory footprint, speed, etc, etc. Most of the
time, people are writing code for a use in the *real world*, and
not just as an academic exercise.

Look at Windows 9x. Big messy mixture of functional and OO coding,
varying APIs, inconsistent, bug-ridden, often unstable and unpredictable.
But, a very successful product commercially. (Before you flame, I'm
not a windows lover...) Partly this is due to marketing and business
practices (very effective ones, whatever you think of Microsoft), and
partly because the products were shipped, new features were added, and the
general perception of users is that the software can "do stuff".

I don't think many end-users of Windows (proportionately) care whether
the code is written in Pascal, Lisp, ALGOL, Objective C; whether the design
was refactored from scratch, or what kind of multiple inheritance/interface/
MVC paradigms were used to construct the code.

There is also More Than One Way To Do It. Lots of tools, things to
make throwaway one-liner code, IDEs, collaborative development tools, frameworks
to aid in OO design, database access, you name it. All of it, though, is
geared at writing software that does something. It may be that you feel that,
if you use a totally OO language (e.g. Java), you will have better code than
if you write it in C; but the metric is, does the software work?

And then TMTOWTDI in a given language environment. Some people like to
have generic base classes, which they subclass to use in a generic application.
A lot of GUI frameworks (MFC, Borland's, QT) seem to be based around this idea.
Others like to write generic classes, which handle any given situation within
their stated problem domain. I like this method: Kind of a "Write Once, Forget
Anywhere" method, where the class implementation is not important once coded,
and (hopefully), you can use the same class in a wide variety of projects,
without having to change the class code.

And so-on.

There are benefits in the form of code-reuse, encapsulation, etc. But making
code OO doesn't make it good code. (Cool is not always Va-Va-Voom, to quote
a recent car advert...) I doubt many people could point to a non-trivial
DB app, that uses a 5NF database design, that couldn't be improved with some
denormalization of the data. Applying an academic theory to a problem doesn't
guarantee to solve it, it just helps you analyze what's going on. And "My" idea
of OO design doesn't necessarily match with "Yours" - it's just different.

Matt

matty:
[color=blue]
> Look at Windows 9x. Big messy mixture of functional and OO coding,
> varying APIs, inconsistent, bug-ridden, often unstable and unpredictable.[/color]

Well what you're saying is that it sucks. We want software that is bug-free.
stable and predictable. So we clearly don't want to code stuff the Windows
way.
[color=blue]
> I don't think many end-users of Windows (proportionately) care whether
> the code is written in Pascal, Lisp, ALGOL, Objective C; whether the
> design was refactored from scratch, or what kind of multiple
> inheritance/interface/ MVC paradigms were used to construct the code.[/color]

Of course not. But we as programmers care for our craft, and for us these
are extremely important issues because we want to produce high quality
products. And this obviously benefits end-users in the long run.
[color=blue]
> There is also More Than One Way To Do It. Lots of tools, things to
> make throwaway one-liner code, IDEs, collaborative development tools,
> frameworks
> to aid in OO design, database access, you name it. All of it, though, is
> geared at writing software that does something. It may be that you feel
> that, if you use a totally OO language (e.g. Java), you will have better
> code than if you write it in C; but the metric is, does the software work?[/color]

But each language has it's collection common knowledge known as
best-practices. If you want to write good software in whatever language you
choose there are basically two approaches:

A) I'm so much smarter than all the people who have worked with this
language before, I can do it better, because I *really* know how it should
be done. Screw the best-practices and the knowledge they have collected
through decades of experience, I'll do it my way.

B) I'll better listen to the masters if I want to be an expert in this
language.

Guess what approach I prefer.
[color=blue]
> And then TMTOWTDI in a given language environment. Some people like to
> have generic base classes, which they subclass to use in a generic
> application. A lot of GUI frameworks (MFC, Borland's, QT) seem to be based
> around this idea. Others like to write generic classes, which handle any
> given situation within
> their stated problem domain. I like this method: Kind of a "Write Once,
> Forget Anywhere" method, where the class implementation is not important
> once coded, and (hopefully), you can use the same class in a wide variety
> of projects, without having to change the class code.[/color]

There are of course different ways of doing things that apply to different
circumstances. That's why we have so many different programming languages.
There is no language to end all languages, nor is there a single
methodology that always works. Best-practices always apply within a
context, nobody ever said that you should always use them, although newbies
tend to do that. But they are best-practices for a *reason*.

André Næss

On Sun, 17 Aug 2003 08:16:10 -0500, in message
<bhnnu7$i1i$1@maud.ifi.uio.no>,"André Næss"
<andrena.spamreallysucks@ifi.uio.no> wrote:
[color=blue]
> [...] each language has it's collection common knowledge known as
> best-practices. If you want to write good software in whatever language
> you choose there are basically two approaches:
>
> A) I'm so much smarter than all the people who have worked with this
> language before, I can do it better, because I *really* know how it
> should be done. Screw the best-practices and the knowledge they have
> collected through decades of experience, I'll do it my way.
>
> B) I'll better listen to the masters if I want to be an expert in this
> language.
>
> Guess what approach I prefer.
>
> [ rest snipped ][/color]

Ah yes, but the best way to learn to do B is
to first screw up a few projects by trying
to do A :-)

I have just spotted this post in my newsreader at home (I have been working
abroad for 2 months where I have been limited to google groups) and I feel I
cannot let it pass without comment.

"André Næss" <andrena.spamreallysucks@ifi.uio.no> wrote in message
news:bhnnu7$i1i$1@maud.ifi.uio.no...[color=blue]
> matty:
>[color=green]
> > Look at Windows 9x. Big messy mixture of functional and OO coding,
> > varying APIs, inconsistent, bug-ridden, often unstable and[/color][/color]
unpredictable.[color=blue]
>
> Well what you're saying is that it sucks. We want software that is[/color]
bug-free.[color=blue]
> stable and predictable. So we clearly don't want to code stuff the Windows
> way.
>[color=green]
> > I don't think many end-users of Windows (proportionately) care whether
> > the code is written in Pascal, Lisp, ALGOL, Objective C; whether the
> > design was refactored from scratch, or what kind of multiple
> > inheritance/interface/ MVC paradigms were used to construct the code.[/color]
>
> Of course not. But we as programmers care for our craft, and for us these
> are extremely important issues because we want to produce high quality
> products. And this obviously benefits end-users in the long run.
>[color=green]
> > There is also More Than One Way To Do It. Lots of tools, things to
> > make throwaway one-liner code, IDEs, collaborative development tools,
> > frameworks
> > to aid in OO design, database access, you name it. All of it, though,[/color][/color]
is[color=blue][color=green]
> > geared at writing software that does something. It may be that you feel
> > that, if you use a totally OO language (e.g. Java), you will have better
> > code than if you write it in C; but the metric is, does the software[/color][/color]
work?[color=blue]
>
> But each language has it's collection common knowledge known as
> best-practices. If you want to write good software in whatever language[/color]
you[color=blue]
> choose there are basically two approaches:[/color]

I have been a software engineer for 25 years using a variety of 2nd, 3rd and
4th generation langages, I have worked on many projects for many
organisations, and I have observed that every different organisation has its
own idea of what constitutes "best practice" as every organisation has its
own version of a "development standards" document. Sometimes I have even
found different groups within the same organisation which have their own
version of the development standards. These "standards" were usually written
by a senior member of the project team, or in some cases handed down by a
project manager from the last project he worked on, and they do not identify
"best practice" across the industry as a whole, they simply reflect the
(in)experience or (in)competence of the individual author. In a great deal
of cases the authors of these documents regard them as being perfect and
will not discuss changes even if you show them a better way of doing
something, something which is faster to develop or which removes a common
cause of bugs.

So when you say "each language has it's collection of common knowledge known
as best practice" I must disagree. Each GROUP OF DEVELOPERS has its own
collection of common knowledge. The only way that standards from one group
are adopted by another is when developers change groups. In my experience
there are very few developers who have the ability to actually create high
quality development standards. They simply use what they are given without
question. When they move to a new project they simply take the previous
project's standards with them and carry on using them "as is" without the
slightest attempt to introduce improvments.

You (and others like you) seem to imply that there is a set of development
standards which applies to the industry as a whole and not just a particular
group. Have these standards been published anywhere? What is the level of
competence of the authors? What is their justification for their "rules"?

When I develop in any particlar language the only rules I wll accept are
contained within the language's Reference Manual. It tells me what commands
are available and what they do. How I use those commands is entirely up to
me. At the end of the day it is the results which I achieve and not the way
that I achieved them which is most important. I will NEVER put methodology
in front of results.
[color=blue]
> A) I'm so much smarter than all the people who have worked with this
> language before, I can do it better, because I *really* know how it should
> be done. Screw the best-practices and the knowledge they have collected
> through decades of experience, I'll do it my way.[/color]

A lot of development standards that I have seen have not been devised after
careful consideration of all the options, of comparing the pros and cons of
different techniques to see which one offers the most advantages or the
least disadvantages, they have simply produced a document which says "this
is the way I do it, now everybody must do the same".
[color=blue]
> B) I'll better listen to the masters if I want to be an expert in this
> language.[/color]

The only "masters" I have come across in my long career are "master baters".
A few years ago I worked on a large contract for a UK government department
in which the project designers insisted on an approach based on a
combination of OO techniques and the 3 tier architecture. They were so
engrossed in producing something that met their particular interpretations
of the rules that they lost sight of the real objective - to produce a
workable solution in a timeframe and to a budger which is acceptable to the
client. To cut a long story short these clowns spent 3 man years developing
an infrastructure, then when it came to building the first two components, a
screen into which you could enter selection criteria followed by a screen
which listed the rows which met that criteria, it took TWO developers TWO
weeks. The original development estimates were based on days per component,
so when these were recalculated using WEEKS instead of DAYS the client
realised that the project would be six months too late and £2 million over
budget. The entire project was immediate cancelled.

It turned out that half of the team had never used the development language
in question, and the other half had only used a previous version. I had used
the current version ever since it had been released and I had created my own
development environment which used the features of that language to achieve
the best results. I warned them that in my experience their approach was all
wrong and would not be acceptable to the client, but they refused to believe
me. "These methods are acceptable to us, they are the way of the future"
they said.

When the project was cancelled these people blamed the language for the
failure and not their methodologies. Just to make a point I went back to my
Head Office and converted my original 2 tier development environment into 3
tier and created the same two components (select and list). It took me just
TWO WEEKS. Not only that, within those two weeks I also created additional
components for insert, update, enquire and delete. When I showed the results
to my former workmates all they could say was "Unacceptable - your methods
are wrong". But guess which method would have been more acceptable to the
client?

Another organisation I visited a few years later advertised themselves as
"innovators" in this particular language, but when I got there and examined
their development standards I just could not believe it. I ended up by
writing a 17 page, 9000 word document which highlighted all the areas where
what they considered to be "best" practice was in fact the "worst" because
they were making the developer do extra work without any discernable
benefit, or in some cases to great disadvantage. I identified all the
different ways in which they could make improvements, but they refused to
believe me. As I had a copy of my own development environment on my laptop I
was able to show them. I took a component which they estimated would take
1.5 days using their methods and built it in 20 minutes using mine. They
were shocked on two counts - first because someone had the balls to tell
them that their methods were crap, and second because that same someone had
the means to prove it.

So when I say that I can take somebody else's development standards and make
drastic improvements I am not just blowing smoke. I have been creating my
own developments standards in different languages for the past 20 years, and
in every case I have knocked all comptetition into a cocked hat. Whatever
somebody says is "best" practice I come along and show them a way which is
"better".
[color=blue]
> Guess what approach I prefer.
>[color=green]
> > And then TMTOWTDI in a given language environment. Some people like to
> > have generic base classes, which they subclass to use in a generic
> > application. A lot of GUI frameworks (MFC, Borland's, QT) seem to be[/color][/color]
based[color=blue][color=green]
> > around this idea. Others like to write generic classes, which handle any
> > given situation within
> > their stated problem domain. I like this method: Kind of a "Write[/color][/color]
Once,[color=blue][color=green]
> > Forget Anywhere" method, where the class implementation is not important
> > once coded, and (hopefully), you can use the same class in a wide[/color][/color]
variety[color=blue][color=green]
> > of projects, without having to change the class code.[/color]
>
> There are of course different ways of doing things that apply to different
> circumstances. That's why we have so many different programming languages.
> There is no language to end all languages, nor is there a single
> methodology that always works.[/color]

I agree entirely.
[color=blue]
> Best-practices always apply within a
> context, nobody ever said that you should always use them,[/color]

That is why I choose not to follow what you consider to be "best practice"
because I have discovered something which I consider to be "better".
[color=blue]
> although newbies
> tend to do that. But they are best-practices for a *reason*.[/color]

When a newbie joins an organisation he/she uses that organisation's
development standards because they are told to. If a newbie is learning a
language at home then he/she may use somebody else's standards simply
because they have got to start somewhere. But that should not prevent
anyone, after gaining experience in the language, from trying out different
methods to see if better results can be achieved. Anyone who follows a set
of standards without question will always be a second-rate programmer, and I
have seen many of those in my long career.

Tony Marston
http://www.tonymarston.net/

Andr¨¦ N?ss <andrena.spamreallysucks@ifi.uio.no> wrote in message news:<bj4v8e$scv$1@maud.ifi.uio.no>...[color=blue]
> Tony Marston:
>[/color]
<snip>[color=blue]
>[color=green]
> > Programming is an art, not a science[/color]
>
> Indeed.
>[color=green]
> > , and different programmers, given
> > the same program to write in the same language, may produce acceptable
> > results but in a totally different style. The only way to say if a
> > program is badly written or well written is to evaluate it on certain
> > points:[/color]
>
> Certainly. But in every language there are things you simply should avoid.[/color]

Then take the matter up with the authors of those languages.

Every language has its own set of commands which are there for each
programmer to use as he sees fit. Some commands are better at
achieving certain results than others, but the purpose of the
programmer is to string together a series of commands in a particular
sequence to achieve a certain result. There is no "right" series or
sequence of commands, just a "right" result. The skill in programming
comes in choosing the most efficient series of commands, eliminating
the possibility of any bugs, and writing code that can be read,
understood and maintained by others as well as by yourself.

Some people may decide to ban certain commands for totally ridiculous
reasons. As an example many years ago I joined a COBOL project team
and read in their development guidelines that the COMPUTE verb was not
to be used. Having used it successfully on previous projects I asked
the project leader the reason why, only to be told "because it is
inefficient". It turned out that he had discovered some junior
programmers were using this verb for simple incrementing (as in:
COMPUTE A = A+1) instead of for complex calculations, but instead of
educating them on how to use the verb efficiently he issued a total
ban. That shows the level of competence I have encountered in people
who are supposed to be my "masters".

In my 25+ years of programming there has only ever been one command
that I have banned from my repertoire and have urged other people to
avoid, and that is the ALTER verb in COBOL. Why? Because it allows an
instruction to be alterered at runtime. Why is this a problem? Have
you tried debugging a program where the instruction that you see in
the source code is different from the one actually being executed? All
I had to do when a fellow programmer thought of using this command was
to explain the potential problem and inform them that if anything went
wrong with the program they would be given the task of debugging it
and their enthusiasm for using it would suddenly evaporate. Issuing a
blanket ban on something without giving a proper explanation,
especially one that can be challenged, is something I find
unacceptable.

So when someone tells me that I must NOT create classes for so-and-so,
and I must NOT use class variables for so-and-so, and I must NOT use
subclassing for so-and-so, I demand to know why. Where are these rules
published? Who wrote them? What is the logic behind them? Where do I
go if I want to challenge this logic?

[color=blue]
> Style guides always say "You really shouldn't do this unless you have a
> good reason", and they do so because years of practice have shown why doing
> so is not a good idea.[/color]

I have seen too many style guides which simply say "Do it *this* way
because I don't like *that* way". Yet when I work with another group
their attitude is "Do it *that* way because I don't like *this* way".
There is no one style which is universally accepted by all groups as
each group chooses its own style based on the limited experiences of
the members of that particular group. Some groups simply latch onto
the first method they come across that works and never bother
experimenting with other methods to see if there is a *better* way.

In any language (and I have used quite a few in my time) there can be
more than one method of achieving a certain result, and no method can
be said to be either *right* or *wrong*, merely *different*. Each
method may have its own set of advantages and disadvantages, and it is
down to the skill of the individual programmer to exploit the
advantages and reduce the disadvantages of any chosen method.

I have come across several cases where a particular group has chosen
method "A" over method "B" simply because they have difficulty in
implementing method "B". I choose method "B" because it produces a
better result, and my skill as a programmer gives me the ability to
overcome any "difficulties" in its implementation. So just because
method "A" is right for them does not mean that method "B" is wrong,
and just because method "B" is right for me does not mean that method
"A" is wrong. Both methods work so neither of them can said to be
"wrong". Any group should be entitled to choose whatever method they
see fit as there is no single method which is "right" for everybody.

When you say that style guides represent "best practice based on years
of experience" I have to disagree. Every particular style guide that I
have ever encountered has represented nothing more than the limited
experience of its authors and not the total experience of the wider
programming community. You will never get all the programmers in any
particular language or methodology to universally agree that any
particular method is either "right" or "wrong", so don't waste your
time trying.

Each programmer or group of programmers should be free to choose
whatever method they see fit to achieve the expected results, and
these programmers should also be free to experiment with new methods
in search of something which may be "better". Any new methods they
discover they may decide to keep secret so that they can gain a
advantage over their competitors, or they may decide to publish them
so that the world at large may benefit from their inventiveness. That
is what I attempted to do when I published my article, only to be told
"WE are the masters, WE have already invented the perfect solution,
HOW DARE YOU think that you could possibly invent something better".
THAT is the attitude that I am fighting against.
[color=blue][color=green]
> > This does not mean that you insist that everybody does things in a
> > rigid fashion as this stifles creativity and prevents improvements
> > from being discovered.[/color]
>
> Nobody has ever threated with the use of force, or in any way insisted on
> anything. This thread has been a simple discussion about design. If I
> believe that a certain way of designing something is better than a
> different way, then of course I will try to explain my view! I've never
> claimed that "best practices" are anything more than *guidelines*.[/color]

Then why is it that certain people out there have not said "your
method may work, but here is a method which I think is better" but
"whether it works or not is irrelevant because it breaks OUR set of
rules". They have given no justification for their rules, just simply
said "this is the way that WE do it, and you are NOT allowed to do it
differently". As I do not see any merit in their so-called "rules" I
see abolutely no reason why I should abide by them. I think they are
just as much rubbish as most of the other "rules" I have encounered in
my long career as a software engineer.
[color=blue][color=green]
> > I have seen programs which ran like greased lightning rejected on the
> > grounds that the programming style was so obtuse that it copuld not be
> > maintained by anyone but the author. This is not acceptable.[/color]
>
> What is not acceptable? That the code was unreadable or that it wasn't
> accepted due to it's unmaintainable nature?[/color]

The code was rejected because none of the other team members could
understand it and none was prepared to maintain it. The author chose
to use a particular set of commands in a rather obscure fashion just
to prove how clever he was, and none of the other team members could
understand how it worked. That is why for the past 20 years I have
favoured a style called "ego-less" programming in which it should not
be possible to determine the author of a piece of work just by looking
at how it is written. Every team member, from the highest to the
lowest, should be able to look at the source code for any program and
think to himself "I might have written that".
[color=blue][color=green][color=darkred]
> >> > The only way that standards from one
> >> > group are adopted by another is when developers change groups. In my
> >> > experience there are very few developers who have the ability to
> >> > actually create high quality development standards.
> >>
> >> Nobody create them, they emerge by the collective work of thousands of
> >> developers. We are not talking about things like the Java Code
> >> Conventions
> >> (http://java.sun.com/docs/codeconv/ht...vTOC.doc.html), although
> >> they are useful too.[/color]
> >
> > But somebody must write them down and publish them, otherwise how are
> > the rest of us supposed to know about them?[/color]
>
> They are written down and published of course, through the WWW, through
> books, through Usenet etc.[/color]

That is the problem. There is too much information out there, and a
great deal of it is conflicting and contradictory, so which do I
choose?

<snip>
[color=blue][color=green]
> > Best practices as defined by one group may be totally different to
> > those being used by another group. I refuse to accept that any one
> > group, however large, can enforce its viewpoint on the rest of the
> > community.[/color]
>
> Of course they can't, and that is not the point. The point is that certain
> things are fairly universally agreed, whereas others may be more debated.
> It always pays to listen to the community when you are new to a language.[/color]

Nothing is universally agreed. Different groups will always have
different viewpoints. None is either "right" or "wrong", merely
"different". Even in the OO community there are some who say that
things like multiple inheritance are the best thing since sliced bread
while others say that they are more trouble than they are worth. There
is yet another group which says that OOP is on its way out and that
AOP (Aspect-Oriented Programming) is the new paradigm.
[color=blue][color=green]
> > But even among all this collected knowledge I bet you will find
> > disagreemnet and different interpretations. Just because one method is
> > right for one person does make make it automatically right for
> > everyone else.[/color]
>
> Err... The *point* of collective knowledge is that it is not the ideas of a
> single person. Unless a method is right for many people it simply isn't
> collective, by definition! This is not a one-to-many relationship, where
> the guru sits at the front of his class disclosing his wisdom. This is more
> like a many-to-one relationship where a huge bunch of mini-gurus sit at the
> front of a neophyte and explain the Tao to him.[/color]

But just because a particular method may be accepted by one part of
the community should not be used as an excuse to prevent anybody from
experimenting with new and different methods. Without experimentation
there will be no innovation and no progress.

<snip>
[color=blue][color=green][color=darkred]
> >> We are not talking about rules in such a strict sense. We've been talking
> >> about common practices,[/color][/color][/color]

But what is common practice to one group may not be common practice to
another. So how do I know which group to follow?
[color=blue][color=green][color=darkred]
> >> things that developers have discovered during
> >> their many years of trial and error.[/color][/color][/color]

But different groups of programmers have discovered different
solutions to similar problems. So how do I know which group to follow?
[color=blue][color=green][color=darkred]
> >> Look at "Design Patterns" by Gamma
> >> et. al. This is just a collection of ideas that many many different
> >> designers had known for years, many of which discovered them all by
> >> themselves.[/color][/color][/color]

But the things which are known to one group of programmers may be
different from the things which are known to another, so which group
do I follow?
[color=blue][color=green][color=darkred]
> >> Hell, when I read it for the first time I even recognized
> >> stuff that I had understood while learning to program Java.[/color]
> >
> > But what may be common to one group of developers may be uncommon to
> > another. Or different groups of developers may have found different
> > solutions to the same problem. Trying to force one solution upon all
> > groups of developers is out of order.[/color]
>
> Yes yes yes :P The point was simply that almost *everyone* I've encountered
> have agreed with a fairly large percentage of the ideas put forth in
> "Design Patterns", so there must be some good ideas there.[/color]

Just because a large number of programmers have decided to use a set
of design patterns which someone has published does not mean that
everyone else should accept them without question. I have my own
patterns which I have been using successfully for the past 10 years,
so why should I switch?

<snip>
[color=blue][color=green]
> > You seem to imply that just because I use different methods from yours
> > that my code is automatically full of bugs and difficult to maintain.
> > That is a false assumption.[/color]
>
> It certainly is a false assumption on your part. I imply no such thing. In
> this thread I argued why I thought a better design was possible, and I
> think I spent some time explaining *why*. You disagreed. So it goes.[/color]

But you argued that by having a separate class for each database table
I was introducing a maintenace problem because I would have to change
the class each time I changed the structure of the table. This
presents no more of a maintenace problem than with any other method. I
don't know how you write programs, but for the past 20 years I have
never written a program which accesses an external file without that
program having some idea of the structure of that file being built
into the code. If you change the structure of the file then you must
change the structure in the code otherwise there will be problems.
Even if you use a language with a data dictionary (and I have been
using such a language for the past 10 years) you cannot change the
structure of the file without changing the reference to that file in
the data dictionary.
[color=blue][color=green]
> > I write code to high standards because it
> > has to be held up as an example to all other programmers in my team.
> > If you take a look at
> > http://www.tonymarston.net/php-mysql/dateclass.html you will see an
> > example of my coding style. Notice how I break up groups of code with
> > blank lines, notice that I use lots of comments. Also notice how I
> > break up the regular expressions into their component parts so that
> > even someone new to regular expressions has a chance to understand
> > them.[/color]
>
> Those are merely style issues. While they are certainly important, I don't
> think they are that relevant to this discussion.[/color]

But that demonstrates that I can write code which is just as readable,
and therefore maintainable, as anyone else. This should be the major
issue here and not "you cannot use that feature of the language in
that way". I must be free to use whatever features of the language
that are available in whatever combination I choose in order to
achieve a result. Provided that the code I produce is well structured,
well documented and can be read, understood and maintained by others
should be the only yardstick. If someone can point to a piece of my
code and say "if you used this bit of code instead of that it would be
more efficient" or "are you aware of a poptential bug in this area"
then I would be prepared to listen. Constructive criticism is always
welcome, but non-constructive criticism is a waste of time.
[color=blue][color=green]
> > Unfortunately all of the "best practices" I have encountered in the
> > past have been the best that a particular individual or small group of
> > individuals can do, and not the collective knowledge of the whole
> > programming community.[/color]
>
> If you have had no experience with the best-practices I've been talking
> about, then why do you still seem so hostile against them?[/color]

Because I see no reason to believe that the "best practices" you are
talking about are any better than the examples of "best practice"
which I have encountered in the past 20 years. My idea of "best
practice" is what produces the best results in the shortest possible
time, while others seem intent on creating a set of innefficient rules
and sticking to them regardless of how long it takes to produce the
results.
[color=blue][color=green]
> > But telling them that there is *only
> > one way* to do things is quite wrong, just as it is wrong to say that
> > there is *only one true religion*. It is correct to identify the
> > difference between different methods, such as "this is faster to
> > implement" or "this has fewer bugs" or "this is easier to maintain",[/color]
>
> But saying "This is better because it leads to better maintainability/faster
> code/fewer bugs" presumably isn't.[/color]

If one method has more advantages and less disadvantages than another
then it can certainly be said to be better. But as far as ths thread
goes nobody has offered me any proof that my method is worse than
theirs. They just assume that just because it is different it is bound
to be inefficient and unmaintainable. Some people have suggested
alternative methods, but I have yet to see any advantage in adopting
them. I will not change my methods unless I see a distinct benefit in
doing so.
[color=blue][color=green]
> > An individual's creativity must
> > be allowed to shine otherwise everything will remain the same and
> > there will never be any progress.[/color]
>
> But it is certainly a shame when an individual's creativity is wasted on
> rediscovering stuff that has been known to fellow craftsmen for decades.[/color]

But different groups *know* different solutions to similar problems,
and my point is that there will never be just one solution to any
given problem. Every solution is *right* and no solution is *wrong*.
Just because there are 100 possible solutions already out there should
not prevent me, or anyone else, from creating solution 101.
[color=blue]
> Reinventing the wheel doesn't exactly generate much progress.[/color]

I am not reinventing the wheel, just devising a different process for
making one, and I am receiving abuse from certain quarters just
because I have created a methodology which is different from theirs.
The fact that the results of my design are just as efficient and
maintainable as anyone else's does not seem to enter the equation.

Tony (you do it your way and I'll do it better) Marston
http://www.tonymarston.net/

"Tony Marston" <tony@NOSPAM.demon.co.uk> wrote in message news:<biv89e$6pq$1$830fa795@news.demon.co.uk>...>[color=blue]
> The only "masters" I have come across in my long career are "master baters".
> A few years ago I worked on a large contract for a UK government department
> in which the project designers insisted on an approach based on a
> combination of OO techniques and the 3 tier architecture. They were so
> engrossed in producing something that met their particular interpretations
> of the rules that they lost sight of the real objective - to produce a
> workable solution in a timeframe and to a budger which is acceptable to the
> client. To cut a long story short these clowns spent 3 man years developing
> an infrastructure, then when it came to building the first two components, a
> screen into which you could enter selection criteria followed by a screen
> which listed the rows which met that criteria, it took TWO developers TWO
> weeks. The original development estimates were based on days per component,
> so when these were recalculated using WEEKS instead of DAYS the client
> realised that the project would be six months too late and £2 million over
> budget. The entire project was immediate cancelled.
>
> It turned out that half of the team had never used the development language
> in question, and the other half had only used a previous version. I had used
> the current version ever since it had been released and I had created my own
> development environment which used the features of that language to achieve
> the best results. I warned them that in my experience their approach was all
> wrong and would not be acceptable to the client, but they refused to believe
> me. "These methods are acceptable to us, they are the way of the future"
> they said.
>
> When the project was cancelled these people blamed the language for the
> failure and not their methodologies. Just to make a point I went back to my
> Head Office and converted my original 2 tier development environment into 3
> tier and created the same two components (select and list). It took me just
> TWO WEEKS. Not only that, within those two weeks I also created additional
> components for insert, update, enquire and delete. When I showed the results
> to my former workmates all they could say was "Unacceptable - your methods
> are wrong". But guess which method would have been more acceptable to the
> client?[/color]

You should send this story to Robert Glass, who does all those books
on software projects gone bad. Maybe he'll use your story in his next
book.

André Næss <andrena.spamreallysucks@ifi.uio.no> wrote in message[color=blue][color=green]
> > Have these standards been published anywhere?[/color]
>
> No and yes. There is no bible, but there is a large body of books and
> articles and newsgroup discussions that all taken together is the collected
> knowledge. Certain books becomes classics, classics are considered such
> because a large number of people view them as such. They might of course
> all be wrong, which is why we have the occasional paradigm shift :)
>[color=green]
> > What is
> > the level of competence of the authors? What is their justification for
> > their "rules"?[/color]
>
> Well since nobody creates the standards I can't answer that very well. All I
> can say that I assume nobody come up with practices because they want to be
> *worse* programmers, so I think it's safe to assume that they do so to
> produce better software, to be better at their craft.
>[color=green]
> > When I develop in any particlar language the only rules I wll accept are
> > contained within the language's Reference Manual. It tells me what
> > commands are available and what they do. How I use those commands is
> > entirely up to me. At the end of the day it is the results which I achieve
> > and not the way that I achieved them which is most important. I will NEVER
> > put methodology in front of results.[/color]
>
> We are not talking about rules in such a strict sense. We've been talking
> about common practices, things that developers have discovered during their
> many years of trial and error. Look at "Design Patterns" by Gamma et. al.
> This is just a collection of ideas that many many different designers had
> known for years, many of which discovered them all by themselves. Hell,
> when I read it for the first time I even recognized stuff that I had
> understood while learning to program Java.[/color]

I think Andre sums it up well. The legal equivalent would be English
Common Law, or perhaps, in general, case law. A civil society will
generate standards with input from every group in the community. The
process is chaotic and contradictory, but as time passes certain
themes repeat, and the themes that repeat become the conventional
wisdom of that society. And sometimes the society is wrong, as Andre
says, and later a paradigm shift occurs.

Now assume "society" above refers to the community of programmers that
work wtih a particular language and you'll see the analogy.

However, some books do a good job of really writing down the core
wisdom of a community. For Java I suggest "Effective Java" by Joshua
Block, which contains 57 rules for writing good Java code. An example
rule: #14 Favor composition over inheritance.

[color=blue]
>
> Of course one shouldn't put methodology in front of results, methodologies
> were created for to achieve better results. But "better results" is not a
> very precise metric. If you can save 10 hours on a 40 hour project then
> that might be tempting to do. But if this results in a total of 40 extra
> maintenance hours for the lifetime of the system then the total result is
> negative. Most best practices are concerned with making system stable,
> bug-free and maintainable, not fast to write. After all, a systems
> lifecycle is normally dominated by the time *after* deployment, not before.
>[color=green][color=darkred]
> >> A) I'm so much smarter than all the people who have worked with this
> >> language before, I can do it better, because I *really* know how it
> >> should be done. Screw the best-practices and the knowledge they have
> >> collected through decades of experience, I'll do it my way.[/color]
> >
> > A lot of development standards that I have seen have not been devised
> > after careful consideration of all the options, of comparing the pros and
> > cons of different techniques to see which one offers the most advantages
> > or the least disadvantages, they have simply produced a document which
> > says "this is the way I do it, now everybody must do the same".[/color]
>
> Some examples would be very enlightening.
>[color=green][color=darkred]
> >> Best-practices always apply within a
> >> context, nobody ever said that you should always use them,[/color]
> >
> > That is why I choose not to follow what you consider to be "best practice"
> > because I have discovered something which I consider to be "better".[/color]
>
> If you discover better ways to do things than what the current population of
> developers seem to prefer you'd better publish it. I'll say one thing,
> there are a lot of terrible programmers working with PHP, I guess mostly
> because it is a widespread language for doing something a lot of people
> seem to want to do. Just looking at a lot of the questions here makes you
> realize that the level of competence is rather low, and that there
> certainly is a long way to go before the best practices start to
> crystalize. But arguments like this thread are an important factor as it
> brings different developers practices under scrutiny.
>
> André Næss[/color]

André N?ss <andrena.spamreallysucks@ifi.uio.no> wrote in message[color=blue]
> If you discover better ways to do things than what the current population of
> developers seem to prefer you'd better publish it. I'll say one thing,
> there are a lot of terrible programmers working with PHP, I guess mostly
> because it is a widespread language for doing something a lot of people
> seem to want to do. Just looking at a lot of the questions here makes you
> realize that the level of competence is rather low, and that there
> certainly is a long way to go before the best practices start to
> crystalize. But arguments like this thread are an important factor as it
> brings different developers practices under scrutiny.[/color]

Inevitable with an easy to learn script language, no? The whole point
is to allow non-programmers to do some programming. And this is the
wave of the future, yes?

tony@marston-home.demon.co.uk (Tony Marston) wrote in message news:<7588a50f.0309090726.72c6bc5e@posting.google. com>...[color=blue]
> Andr¨¦ N?ss <andrena.spamreallysucks@ifi.uio.no> wrote in message news:<bj4v8e$scv$1@maud.ifi.uio.no>...[color=green]
> > Tony Marston:
> > Certainly. But in every language there are things you simply should avoid.[/color]
>
> Then take the matter up with the authors of those languages.[/color]

There is often nothing to be taken up because the flaws of one
language are often a part of its strengths. There is no perfect
language. Should I go to the authors of Java and say "Hey, using Java,
I can't write simple programs as quickly as I write them in PHP!" That
would be a stupid complaint, and they would be right to responsd,
"Then go use PHP!"

What Andre is saying is that you should know the strengths and
weaknesses of a language, and use it for its strengths, and avoid its
weaknesses. For instance, don't try to write 5 line programs in Java.
For something that small, a script language will give you many
benefits and no disadvantages.

[color=blue]
> Some people may decide to ban certain commands for totally ridiculous
> reasons. As an example many years ago I joined a COBOL project team
> and read in their development guidelines that the COMPUTE verb was not
> to be used. Having used it successfully on previous projects I asked
> the project leader the reason why, only to be told "because it is
> inefficient". It turned out that he had discovered some junior
> programmers were using this verb for simple incrementing (as in:
> COMPUTE A = A+1) instead of for complex calculations, but instead of
> educating them on how to use the verb efficiently he issued a total
> ban. That shows the level of competence I have encountered in people
> who are supposed to be my "masters".[/color]

Why are you calling this manager a master? Was he internationally
recognized as such? Did the worldwide community of COBOL programmers
follow his lead and give up using the COMPUTE verb? If not, then
you're talking about something quite different than what Andre was
talking about. Andre is talking about those practices which are so
clearly beneficial that all the programmers of a language, once
exposed to those ideas, tend to use them. You are bringing up a
subject completely unrelated to what Andre was talking about. You have
now written several posts and all of your posts have the same theme.
In all of your posts you talk about bad managers. But Andre is very
clearly not talking about bad managers. He is talking about those
practices that seem so obviously intelligent that everyone will do
them once they are taught them.

An example: in PHP it is possible to break encapsulation by directly
referencing a class variable, rather than getting the value through
an accessor method. If you teach people why this is stupid, then only
the stupid people will continue to do it. Thus, preserving
encapsulation, even when a language allows it, is cleary a practice of
such merit that we can without reservation call it a "best practice."

Your stories of bad managers are entertaining and perhaps you should
send them to Robert Glass. Perhaps he'll use them in his next book.
But you can stop telling such stories in this thread. They are not
relevant. They have nothing to do with what is under discussion. We
are discussing best practices and you keep raising worst practices.

[color=blue]
>
> In my 25+ years of programming there has only ever been one command
> that I have banned from my repertoire and have urged other people to
> avoid, and that is the ALTER verb in COBOL. Why? Because it allows an
> instruction to be alterered at runtime. Why is this a problem? Have
> you tried debugging a program where the instruction that you see in
> the source code is different from the one actually being executed? All
> I had to do when a fellow programmer thought of using this command was
> to explain the potential problem and inform them that if anything went
> wrong with the program they would be given the task of debugging it
> and their enthusiasm for using it would suddenly evaporate. Issuing a
> blanket ban on something without giving a proper explanation,
> especially one that can be challenged, is something I find
> unacceptable.
>
> So when someone tells me that I must NOT create classes for so-and-so,
> and I must NOT use class variables for so-and-so, and I must NOT use
> subclassing for so-and-so, I demand to know why. Where are these rules
> published? Who wrote them? What is the logic behind them? Where do I
> go if I want to challenge this logic?
>
>[color=green]
> > Style guides always say "You really shouldn't do this unless you have a
> > good reason", and they do so because years of practice have shown why doing
> > so is not a good idea.[/color]
>
> I have seen too many style guides which simply say "Do it *this* way
> because I don't like *that* way". Yet when I work with another group
> their attitude is "Do it *that* way because I don't like *this* way".
> There is no one style which is universally accepted by all groups as
> each group chooses its own style based on the limited experiences of
> the members of that particular group. Some groups simply latch onto
> the first method they come across that works and never bother
> experimenting with other methods to see if there is a *better* way.
>
> In any language (and I have used quite a few in my time) there can be
> more than one method of achieving a certain result, and no method can
> be said to be either *right* or *wrong*, merely *different*. Each
> method may have its own set of advantages and disadvantages, and it is
> down to the skill of the individual programmer to exploit the
> advantages and reduce the disadvantages of any chosen method.
>
> I have come across several cases where a particular group has chosen
> method "A" over method "B" simply because they have difficulty in
> implementing method "B". I choose method "B" because it produces a
> better result, and my skill as a programmer gives me the ability to
> overcome any "difficulties" in its implementation. So just because
> method "A" is right for them does not mean that method "B" is wrong,
> and just because method "B" is right for me does not mean that method
> "A" is wrong. Both methods work so neither of them can said to be
> "wrong". Any group should be entitled to choose whatever method they
> see fit as there is no single method which is "right" for everybody.
>
> When you say that style guides represent "best practice based on years
> of experience" I have to disagree. Every particular style guide that I
> have ever encountered has represented nothing more than the limited
> experience of its authors and not the total experience of the wider
> programming community. You will never get all the programmers in any
> particular language or methodology to universally agree that any
> particular method is either "right" or "wrong", so don't waste your
> time trying.
>
> Each programmer or group of programmers should be free to choose
> whatever method they see fit to achieve the expected results, and
> these programmers should also be free to experiment with new methods
> in search of something which may be "better". Any new methods they
> discover they may decide to keep secret so that they can gain a
> advantage over their competitors, or they may decide to publish them
> so that the world at large may benefit from their inventiveness. That
> is what I attempted to do when I published my article, only to be told
> "WE are the masters, WE have already invented the perfect solution,
> HOW DARE YOU think that you could possibly invent something better".
> THAT is the attitude that I am fighting against.
>[color=green][color=darkred]
> > > This does not mean that you insist that everybody does things in a
> > > rigid fashion as this stifles creativity and prevents improvements
> > > from being discovered.[/color]
> >
> > Nobody has ever threated with the use of force, or in any way insisted on
> > anything. This thread has been a simple discussion about design. If I
> > believe that a certain way of designing something is better than a
> > different way, then of course I will try to explain my view! I've never
> > claimed that "best practices" are anything more than *guidelines*.[/color]
>
> Then why is it that certain people out there have not said "your
> method may work, but here is a method which I think is better" but
> "whether it works or not is irrelevant because it breaks OUR set of
> rules". They have given no justification for their rules, just simply
> said "this is the way that WE do it, and you are NOT allowed to do it
> differently". As I do not see any merit in their so-called "rules" I
> see abolutely no reason why I should abide by them. I think they are
> just as much rubbish as most of the other "rules" I have encounered in
> my long career as a software engineer.
>[color=green][color=darkred]
> > > I have seen programs which ran like greased lightning rejected on the
> > > grounds that the programming style was so obtuse that it copuld not be
> > > maintained by anyone but the author. This is not acceptable.[/color]
> >
> > What is not acceptable? That the code was unreadable or that it wasn't
> > accepted due to it's unmaintainable nature?[/color]
>
> The code was rejected because none of the other team members could
> understand it and none was prepared to maintain it. The author chose
> to use a particular set of commands in a rather obscure fashion just
> to prove how clever he was, and none of the other team members could
> understand how it worked. That is why for the past 20 years I have
> favoured a style called "ego-less" programming in which it should not
> be possible to determine the author of a piece of work just by looking
> at how it is written. Every team member, from the highest to the
> lowest, should be able to look at the source code for any program and
> think to himself "I might have written that".
>[color=green][color=darkred]
> > >> > The only way that standards from one
> > >> > group are adopted by another is when developers change groups. In my
> > >> > experience there are very few developers who have the ability to
> > >> > actually create high quality development standards.
> > >>
> > >> Nobody create them, they emerge by the collective work of thousands of
> > >> developers. We are not talking about things like the Java Code
> > >> Conventions
> > >> (http://java.sun.com/docs/codeconv/ht...vTOC.doc.html), although
> > >> they are useful too.
> > >
> > > But somebody must write them down and publish them, otherwise how are
> > > the rest of us supposed to know about them?[/color]
> >
> > They are written down and published of course, through the WWW, through
> > books, through Usenet etc.[/color]
>
> That is the problem. There is too much information out there, and a
> great deal of it is conflicting and contradictory, so which do I
> choose?
>
> <snip>
>[color=green][color=darkred]
> > > Best practices as defined by one group may be totally different to
> > > those being used by another group. I refuse to accept that any one
> > > group, however large, can enforce its viewpoint on the rest of the
> > > community.[/color]
> >
> > Of course they can't, and that is not the point. The point is that certain
> > things are fairly universally agreed, whereas others may be more debated.
> > It always pays to listen to the community when you are new to a language.[/color]
>
> Nothing is universally agreed. Different groups will always have
> different viewpoints. None is either "right" or "wrong", merely
> "different". Even in the OO community there are some who say that
> things like multiple inheritance are the best thing since sliced bread
> while others say that they are more trouble than they are worth. There
> is yet another group which says that OOP is on its way out and that
> AOP (Aspect-Oriented Programming) is the new paradigm.
>[color=green][color=darkred]
> > > But even among all this collected knowledge I bet you will find
> > > disagreemnet and different interpretations. Just because one method is
> > > right for one person does make make it automatically right for
> > > everyone else.[/color]
> >
> > Err... The *point* of collective knowledge is that it is not the ideas of a
> > single person. Unless a method is right for many people it simply isn't
> > collective, by definition! This is not a one-to-many relationship, where
> > the guru sits at the front of his class disclosing his wisdom. This is more
> > like a many-to-one relationship where a huge bunch of mini-gurus sit at the
> > front of a neophyte and explain the Tao to him.[/color]
>
> But just because a particular method may be accepted by one part of
> the community should not be used as an excuse to prevent anybody from
> experimenting with new and different methods. Without experimentation
> there will be no innovation and no progress.
>
> <snip>
>[color=green][color=darkred]
> > >> We are not talking about rules in such a strict sense. We've been talking
> > >> about common practices,[/color][/color]
>
> But what is common practice to one group may not be common practice to
> another. So how do I know which group to follow?
>[color=green][color=darkred]
> > >> things that developers have discovered during
> > >> their many years of trial and error.[/color][/color]
>
> But different groups of programmers have discovered different
> solutions to similar problems. So how do I know which group to follow?
>[color=green][color=darkred]
> > >> Look at "Design Patterns" by Gamma
> > >> et. al. This is just a collection of ideas that many many different
> > >> designers had known for years, many of which discovered them all by
> > >> themselves.[/color][/color]
>
> But the things which are known to one group of programmers may be
> different from the things which are known to another, so which group
> do I follow?
>[color=green][color=darkred]
> > >> Hell, when I read it for the first time I even recognized
> > >> stuff that I had understood while learning to program Java.
> > >
> > > But what may be common to one group of developers may be uncommon to
> > > another. Or different groups of developers may have found different
> > > solutions to the same problem. Trying to force one solution upon all
> > > groups of developers is out of order.[/color]
> >
> > Yes yes yes :P The point was simply that almost *everyone* I've encountered
> > have agreed with a fairly large percentage of the ideas put forth in
> > "Design Patterns", so there must be some good ideas there.[/color]
>
> Just because a large number of programmers have decided to use a set
> of design patterns which someone has published does not mean that
> everyone else should accept them without question. I have my own
> patterns which I have been using successfully for the past 10 years,
> so why should I switch?
>
> <snip>
>[color=green][color=darkred]
> > > You seem to imply that just because I use different methods from yours
> > > that my code is automatically full of bugs and difficult to maintain.
> > > That is a false assumption.[/color]
> >
> > It certainly is a false assumption on your part. I imply no such thing. In
> > this thread I argued why I thought a better design was possible, and I
> > think I spent some time explaining *why*. You disagreed. So it goes.[/color]
>
> But you argued that by having a separate class for each database table
> I was introducing a maintenace problem because I would have to change
> the class each time I changed the structure of the table. This
> presents no more of a maintenace problem than with any other method. I
> don't know how you write programs, but for the past 20 years I have
> never written a program which accesses an external file without that
> program having some idea of the structure of that file being built
> into the code. If you change the structure of the file then you must
> change the structure in the code otherwise there will be problems.
> Even if you use a language with a data dictionary (and I have been
> using such a language for the past 10 years) you cannot change the
> structure of the file without changing the reference to that file in
> the data dictionary.
>[color=green][color=darkred]
> > > I write code to high standards because it
> > > has to be held up as an example to all other programmers in my team.
> > > If you take a look at
> > > http://www.tonymarston.net/php-mysql/dateclass.html you will see an
> > > example of my coding style. Notice how I break up groups of code with
> > > blank lines, notice that I use lots of comments. Also notice how I
> > > break up the regular expressions into their component parts so that
> > > even someone new to regular expressions has a chance to understand
> > > them.[/color]
> >
> > Those are merely style issues. While they are certainly important, I don't
> > think they are that relevant to this discussion.[/color]
>
> But that demonstrates that I can write code which is just as readable,
> and therefore maintainable, as anyone else. This should be the major
> issue here and not "you cannot use that feature of the language in
> that way". I must be free to use whatever features of the language
> that are available in whatever combination I choose in order to
> achieve a result. Provided that the code I produce is well structured,
> well documented and can be read, understood and maintained by others
> should be the only yardstick. If someone can point to a piece of my
> code and say "if you used this bit of code instead of that it would be
> more efficient" or "are you aware of a poptential bug in this area"
> then I would be prepared to listen. Constructive criticism is always
> welcome, but non-constructive criticism is a waste of time.
>[color=green][color=darkred]
> > > Unfortunately all of the "best practices" I have encountered in the
> > > past have been the best that a particular individual or small group of
> > > individuals can do, and not the collective knowledge of the whole
> > > programming community.[/color]
> >
> > If you have had no experience with the best-practices I've been talking
> > about, then why do you still seem so hostile against them?[/color]
>
> Because I see no reason to believe that the "best practices" you are
> talking about are any better than the examples of "best practice"
> which I have encountered in the past 20 years. My idea of "best
> practice" is what produces the best results in the shortest possible
> time, while others seem intent on creating a set of innefficient rules
> and sticking to them regardless of how long it takes to produce the
> results.
>[color=green][color=darkred]
> > > But telling them that there is *only
> > > one way* to do things is quite wrong, just as it is wrong to say that
> > > there is *only one true religion*. It is correct to identify the
> > > difference between different methods, such as "this is faster to
> > > implement" or "this has fewer bugs" or "this is easier to maintain",[/color]
> >
> > But saying "This is better because it leads to better maintainability/faster
> > code/fewer bugs" presumably isn't.[/color]
>
> If one method has more advantages and less disadvantages than another
> then it can certainly be said to be better. But as far as ths thread
> goes nobody has offered me any proof that my method is worse than
> theirs. They just assume that just because it is different it is bound
> to be inefficient and unmaintainable. Some people have suggested
> alternative methods, but I have yet to see any advantage in adopting
> them. I will not change my methods unless I see a distinct benefit in
> doing so.
>[color=green][color=darkred]
> > > An individual's creativity must
> > > be allowed to shine otherwise everything will remain the same and
> > > there will never be any progress.[/color]
> >
> > But it is certainly a shame when an individual's creativity is wasted on
> > rediscovering stuff that has been known to fellow craftsmen for decades.[/color]
>
> But different groups *know* different solutions to similar problems,
> and my point is that there will never be just one solution to any
> given problem. Every solution is *right* and no solution is *wrong*.
> Just because there are 100 possible solutions already out there should
> not prevent me, or anyone else, from creating solution 101.
>[color=green]
> > Reinventing the wheel doesn't exactly generate much progress.[/color]
>
> I am not reinventing the wheel, just devising a different process for
> making one, and I am receiving abuse from certain quarters just
> because I have created a methodology which is different from theirs.
> The fact that the results of my design are just as efficient and
> maintainable as anyone else's does not seem to enter the equation.
>
> Tony (you do it your way and I'll do it better) Marston
> http://www.tonymarston.net/[/color]

lkrubner@geocities.com (lawrence) wrote in message news:<da7e68e8.0309091342.700d2cc1@posting.google. com>...[color=blue]
> André Næss <andrena.spamreallysucks@ifi.uio.no> wrote in message
>[color=green]
> > We are not talking about rules in such a strict sense. We've been talking
> > about common practices, things that developers have discovered during their
> > many years of trial and error. Look at "Design Patterns" by Gamma et. al.
> > This is just a collection of ideas that many many different designers had
> > known for years, many of which discovered them all by themselves. Hell,
> > when I read it for the first time I even recognized stuff that I had
> > understood while learning to program Java.[/color]
>
> I think Andre sums it up well. The legal equivalent would be English
> Common Law, or perhaps, in general, case law.[/color]

At least the laws of the land, regardless of their origin, are all
documented and are available in law libraries. These so-called
theories of "best practice" are not maintained in any sort of a
central library where individuals can refer to them. They exist all
over the place and often one set of theories contradict another, so
how is anybody to know which theory to follow? I consider these
different theories to be analogous to religions where the acolytes
always believe that *their* brand is the one true religion and
everybody else is a blasphemer or a devil worshipper.

The only "laws" that can be applied in any programming language are
documented in that language's reference manual. All these different
methodologies are nothing more than "religions" that any individual
may choose to follow (or not) as he/she sees fit.
[color=blue]
> A civil society will
> generate standards with input from every group in the community.[/color]

I am not interested I "standards" that may vary from group to group, I
am talking about "laws" that one group tries to impose on another.
Standards can vary from one group to another, but laws apply to
everybody.
[color=blue]
> The process is chaotic and contradictory, but as time passes certain
> themes repeat, and the themes that repeat become the conventional
> wisdom of that society. And sometimes the society is wrong, as Andre
> says, and later a paradigm shift occurs.
>
> Now assume "society" above refers to the community of programmers that
> work wtih a particular language and you'll see the analogy.[/color]

The only analogy that I can see is that one group in society has a set
of "standards" which it now wants treated as a set of "laws" which it
can impose on others.

As far as I am concerned the only "universal standard" that I am
prepared to follow is *how* to write code, not *what* code to write.
Good code should be well structured, well documented, readable and
readily maintainable by other programmers. When it comes to the
commands that I use, or how I use them, that is nobody's business but
mine.
[color=blue]
> However, some books do a good job of really writing down the core
> wisdom of a community. For Java I suggest "Effective Java" by Joshua
> Block, which contains 57 rules for writing good Java code. An example
> rule: #14 Favor composition over inheritance.[/color]

I have read the Java Code Conventions at
http://java.sun.com/docs/codeconv/ht...nvTOC.doc.html and they
seem quite reasonable to me. But notice how the emphasis is on "how to
write code that is readable" and not "what code to write". It does not
say "you must use classes in *this* way and not *that* way" or "you
must use class variables for *this* purpose and not *that* purpose" or
"you must use subclassing and inheritance in *this* way and not *that*
way".

Tony (do you want it done your way, or do you want it done properly?)
Marston
http://www.tonymarston.net/

lkrubner@geocities.com (lawrence) wrote in message news:<da7e68e8.0309091426.48d75548@posting.google. com>...[color=blue]
> tony@marston-home.demon.co.uk (Tony Marston) wrote in message news:<7588a50f.0309090726.72c6bc5e@posting.google. com>...[color=green]
> > Andr¨¦ N?ss <andrena.spamreallysucks@ifi.uio.no> wrote in message news:<bj4v8e$scv$1@maud.ifi.uio.no>...[color=darkred]
> > > Tony Marston:
> > > Certainly. But in every language there are things you simply should avoid.[/color]
> >
> > Then take the matter up with the authors of those languages.[/color]
>
> There is often nothing to be taken up because the flaws of one
> language are often a part of its strengths. There is no perfect
> language. Should I go to the authors of Java and say "Hey, using Java,
> I can't write simple programs as quickly as I write them in PHP!" That
> would be a stupid complaint, and they would be right to responsd,
> "Then go use PHP!"
>
> What Andre is saying is that you should know the strengths and
> weaknesses of a language, and use it for its strengths, and avoid its
> weaknesses. For instance, don't try to write 5 line programs in Java.
> For something that small, a script language will give you many
> benefits and no disadvantages.[/color]

All this has got nothing to do with my original argument, which is
that I have been told:
a) I must not create a separate class for each table in my database.
b) I must not create an abstract database class and have each table
class as a subclass.
c) I must not use class variables to hold the components of the sql
LIMIT clause.

[color=blue][color=green]
> > Some people may decide to ban certain commands for totally ridiculous
> > reasons. As an example many years ago I joined a COBOL project team
> > and read in their development guidelines that the COMPUTE verb was not
> > to be used. Having used it successfully on previous projects I asked
> > the project leader the reason why, only to be told "because it is
> > inefficient". It turned out that he had discovered some junior
> > programmers were using this verb for simple incrementing (as in:
> > COMPUTE A = A+1) instead of for complex calculations, but instead of
> > educating them on how to use the verb efficiently he issued a total
> > ban. That shows the level of competence I have encountered in people
> > who are supposed to be my "masters".[/color]
>
> Why are you calling this manager a master? Was he internationally
> recognized as such?[/color]

When you are learning a language your superiors at your place of
employment are supposed to be ¡°the masters¡± based upon their
supposedly superior experience. When they give you their ideas of
¡°best practice¡± in the form of project development standards you are
supposed to believe everything that they say and follow it religiously
without question. You are not allowed to go to outside sources for
their ideas on what consitutes ¡°best practice¡±.
[color=blue]
> Did the worldwide community of COBOL programmers
> follow his lead and give up using the COMPUTE verb?[/color]

You have hit the nail on the head! The worldwide community of COBOL
programmers did not follow his lead simply because his idea of ¡°best
practice¡± was totally different from theirs. But if that version of
¡°best practice¡± can be treated as rubbish, then why can¡¯t others? Who
is to say that somebody else¡¯s version of ¡°best practice¡± is not just
as much rubbish as that one? Just because something is labelled ¡°best
practice¡± does not necessarily make it so. THAT is my point.
[color=blue]
> If not, then
> you're talking about something quite different than what Andre was
> talking about. Andre is talking about those practices which are so
> clearly beneficial that all the programmers of a language, once
> exposed to those ideas, tend to use them.[/color]

Most programmers follow standards because they are told to, not
because they choose to. This should prevent them from examining those
standards in detail to find out if the logic behind them is actually
sound, or if any parts have been superseded by updates to the
language. When it comes to designing solutions to a problem they
should not be prevented from trying alternative methods as they may
discover new methods which are actually superior. Just because
somebody has found a method that works does not give them
justification to enforce that method on everybody else.
[color=blue]
> You are bringing up a
> subject completely unrelated to what Andre was talking about. You have
> now written several posts and all of your posts have the same theme.
> In all of your posts you talk about bad managers.[/color]

You are missing the point. All these managers produced development
standards and methodologies which were supposed to be examples of best
practice but which were clearly no such thing. There are a multitude
of different methodologies and practices out there, and how many of
them are actually worth less than the paper they are written on? If
most of the standards that I have been exposed to have been rubbish,
then what percentage of the standards that I have not yet been exposed
to will turn out to be just as much rubbish.
[color=blue]
> But Andre is very
> clearly not talking about bad managers. He is talking about those
> practices that seem so obviously intelligent that everyone will do
> them once they are taught them.[/color]

Obviously intelligent to who? These managers and project leaders all
thought that their ideas were the best thing since sliced bread, but
they clearly were not. How many of the ideas floating around today are
equally as bad? What I am objecting to is that some people think that
their ideas are absolutely brilliant and they think that everybody
else should follow them without question. Well I *DO* question them
because I think the logic behind them is unsound.
[color=blue]
> An example: in PHP it is possible to break encapsulation by directly
> referencing a class variable, rather than getting the value through
> an accessor method.[/color]

This ¡°problem¡± is not limited to PHP as every language ever written
which supports OO has included support for both public and private
variables. If it breaks encapsulation as you suggest, then why does a
methodology which is supposed to support encapsulation provide the
means to break it?
[color=blue]
> If you teach people why this is stupid, then only
> the stupid people will continue to do it. Thus, preserving
> encapsulation, even when a language allows it, is cleary a practice of
> such merit that we can without reservation call it a "best practice."[/color]

Your description of the problem as ¡°it breaks encapsulation¡± is a load
of technical mumbo-jumbo that has absolutely nothing to do with the
real facts. The correct definition of the ¡°problem¡± goes something
like this: If you access a class variable directly instead of through
an accessor method then this *MAY* lead to maintenance problems in the
future if it is decided that the variable requires extra processing
after it has been input or before it is output. By routing all
accesses through a method means that changes need only be made to that
method rather than all those numerous other places where the variable
is accessed.

Note that this MAY lead to a problem, not WILL. Also note that the
potential ¡°problem¡± is one of simple maintenance and not any sort of
program failure. If all variables were accessed this way then the
potential maintenance problem could be quite large, but if few
variables are accessed this way then the potential problem is greatly
reduced.

I have accessor methods for most of my variables, but there are some
cases where I simply don¡¯t bother because it is not necessary. An
example is where I inject a series of values into an object then
immediately call a method to process them. If I need to change the way
in which these variables are handled all I need to is change the
existing method ? I do not have to go back to any of the code which
injects those variables.

So you see that there MAY be a problem with public variables if they
are used indiscriminately, but there MAY NOT be a problem if they are
used wisely. Just as with the COMPUTE verb which is only inefficient
when used unwisely.

So your statemement that public variables are stupid and should never
be used is just as shortsighted as that project leader who told me
that the COMPUTE verb is inefficient and should never be used.
[color=blue]
> Your stories of bad managers are entertaining and perhaps you should
> send them to Robert Glass. Perhaps he'll use them in his next book.
> But you can stop telling such stories in this thread. They are not
> relevant. They have nothing to do with what is under discussion. We
> are discussing best practices and you keep raising worst practices.[/color]

But these worst practices were promoted as best practices by their
authors. If they were clearly no such thing, then how much of what is
promoted today as best practice will be eventually consigned to the
rubbish bin?

Tony (you do it your way and I'll do it better) Marston
http://www.tonymarston.net/

Tony Marston:
[color=blue][color=green]
>> But Andre is very
>> clearly not talking about bad managers. He is talking about those
>> practices that seem so obviously intelligent that everyone will do
>> them once they are taught them.[/color]
>
> Obviously intelligent to who? These managers and project leaders all
> thought that their ideas were the best thing since sliced bread, but
> they clearly were not. How many of the ideas floating around today are
> equally as bad? What I am objecting to is that some people think that
> their ideas are absolutely brilliant and they think that everybody
> else should follow them without question. Well I *DO* question them
> because I think the logic behind them is unsound.[/color]

We have all the time been talking about the community of programmers.
Developers. Techies. Geeks. We who feel like we are artists, trapped in a
world of pin stripe suits. The logic (or rather lack thereof) in the
software industry is of little interest to this discussion. The gap between
programmers and their managers is covered in "The Career Programmer:
Guerilla Tactics for an Imperfect World" by Christopher Duncan. I just
bought it, and I like it so far, and since you brought it up I just wanted
to tell you about it.

The fact that managers are clueless when it comes to technology is news to
none :) And it really isn't what we've been discussing here. The sort of
best practices we have been talking about are those that most developers
nod their head at in recognition, maybe they have already come to the same
conclusion through their own experience, or maybe the truth of the idea
hits them right away.

André Næss

André Næss <andrena.spamreallysucks@ifi.uio.no> wrote in message news:<bjs76b$7be$1@maud.ifi.uio.no>...[color=blue]
> Tony Marston:
>[color=green][color=darkred]
> >> But Andre is very
> >> clearly not talking about bad managers. He is talking about those
> >> practices that seem so obviously intelligent that everyone will do
> >> them once they are taught them.[/color]
> >
> > Obviously intelligent to who? These managers and project leaders all
> > thought that their ideas were the best thing since sliced bread, but
> > they clearly were not. How many of the ideas floating around today are
> > equally as bad? What I am objecting to is that some people think that
> > their ideas are absolutely brilliant and they think that everybody
> > else should follow them without question. Well I *DO* question them
> > because I think the logic behind them is unsound.[/color]
>
> We have all the time been talking about the community of programmers.
> Developers. Techies. Geeks. We who feel like we are artists, trapped in a
> world of pin stripe suits. The logic (or rather lack thereof) in the
> software industry is of little interest to this discussion. The gap between
> programmers and their managers is covered in "The Career Programmer:
> Guerilla Tactics for an Imperfect World" by Christopher Duncan. I just
> bought it, and I like it so far, and since you brought it up I just wanted
> to tell you about it.
>
> The fact that managers are clueless when it comes to technology is news to
> none :)[/color]

But all of these people were senior programmers, project leaders and
such, not just pin-striped geeks from the admin department. As such
they should have been imparting best practices from their own
experience, but what they were actually teaching was very limited and
in most cases nowehere near what should have been considered as best
practice.

Because these technicians were capable of producing crap standards I
am immediately suspicious of everybody else's until I can personally
put them to the test and verify them, and in a lot of cases compare
them with what I have encountered in my own experience.
[color=blue]
> And it really isn't what we've been discussing here. The sort of
> best practices we have been talking about are those that most developers
> nod their head at in recognition, maybe they have already come to the same
> conclusion through their own experience, or maybe the truth of the idea
> hits them right away.
>
> André Næss[/color]

There is a great deal of difference between best practice when it
comes to avoiding common errors and best practice when it comes to
designing a solution. Provided that a particular design or methodology
produces a workable solution then it is wrong for others to tell me
that I must not design that way or use a methodology that is different
from theirs. I am allowed to use what ever design I see fit and to use
whatever methodology I see fit without some nerd leaning over my
shoulder and say "you must not do it that way". Unless you can point
out a genuine problem with my work then any criticism is unfounded.

I choose to use public variables because the language allows me to,
and because I don't have a problem with them.

I choose to create a class for each database table because the
language allows me to, and they work very well thank you very much.

I choose to have my individual database table classes inherit lots of
standard variables and methods from an abstract database class because
the language allows me to, and because it enables me to have a great
deal of standard code which I can write once and use many times.

All these arguments about what different groups of programmers may
consider to be best practice is a smoke screen. If you can point out
genuine problems with my methodology or my design then I will be in
your debt, but please stop telling me that what I am doing is wrong
because it is different from the way you would do it. My software
works therefore it cannot be wrong.

Tony (go on punk, make my day) Marston
http://www.tonymarston.net/

On 12 Sep 2003 07:27:27 -0700, Tony Marston wrote:
[color=blue][color=green]
>> The fact that managers are clueless when it comes to technology is news to
>> none :)[/color]
>
>But all of these people were senior programmers, project leaders and
>such, not just pin-striped geeks from the admin department. As such
>they should have been imparting best practices from their own
>experience, but what they were actually teaching was very limited and
>in most cases nowehere near what should have been considered as best
>practice.[/color]

there is a certain confusion here, it seems to me. i agree with the
one side of the argument that there is a certain, somewhat imprecisely
defined though, set of rules that make up those best practices. it is,
however, not well-defined enough to be a good guideline for any team
(or individual).

therefore a team leader usually has to come up with a certain subset
(or superset) of thore practices, defined enough to make the team work
consistently and understand each other. this set of rules has a
somewhat different objective, and therefore it might diverge from some
commonly accepted best practices -- and definitely often diverges from
individual's preferences -- and still be adequate for the team.

i don't know about the situation around the earlier cited cobol case
with the compute verb. but let's assume that 50% of the team members
were not capable of using that verb reliably, then it might make sense
in the context of that project and that team to set up such a rule.
(might not be the best example, but you get the idea: the rules
necessary for a team are quite different from the rules for an
individual.)

[color=blue]
>I choose to use public variables because the language allows me to,
>and because I don't have a problem with them.
>
>I choose to create a class for each database table because the
>language allows me to, and they work very well thank you very much.
>
>I choose to have my individual database table classes inherit lots of
>standard variables and methods from an abstract database class because
>the language allows me to, and because it enables me to have a great
>deal of standard code which I can write once and use many times.[/color]

since i put in here some cents of mine, i jut wanted to mention that i
for my part don't have a problem with this design :)

in general i tend to create an abstraction when i add another layer,
which usually would lead to classes that do not 100% reflect the
underlying tables. but then, there are all kinds of situations where
something like what you do makes sense...

in any case, i wouldn't know of a PHP best practice that says that you
shouldn't wrap your tables into classes :))

tony@marston-home.demon.co.uk (Tony Marston) wrote in message news:<7588a50f.0309110701.2b9ecd8f@posting.google. com>...> You are bringing up a[color=blue][color=green]
>> subject completely unrelated to what Andre was talking about. You[/color][/color]
have[color=blue][color=green]
>> now written several posts and all of your posts have the same[/color][/color]
theme.[color=blue][color=green]
>> In all of your posts you talk about bad managers.[/color]
>
>You are missing the point. All these managers produced development
>standards and methodologies which were supposed to be examples of[/color]
best[color=blue]
>practice but which were clearly no such thing. There are a multitude
>of different methodologies and practices out there, and how many of
>them are actually worth less than the paper they are written on? If
>most of the standards that I have been exposed to have been rubbish,
>then what percentage of the standards that I have not yet been[/color]
exposed[color=blue]
>to will turn out to be just as much rubbish.[/color]

At this point we're simply repeating ourselves. Your point was that
there are bad managers in this world who promote bad practice and call
it good practice. I understood you the first time you made that point,
as well as the 2nd, 3rd, 4th, and 5th time you made that point. Once
would have been enough.

I pointed out that your point wasn't germane to the discussion because
we weren't talking about what managers do, we were talking about what
the programmers using a language do. If all the programmers using one
language adopt some practice because it seems great then that becomes
a "best practice" for the language. Look around and you'll see dozens
of examples of this everyday. "Don't break encapsulation" is a good
example of a "best practice". As Andre said, these are guidelines, not
hard rules, but everyone using a language usually is admonished to use
the guideline when they can.

As I said before, your examples of bad managers are entertaining, and
I enjoyed reading them, but they are not what we are talking about. We
are talking about those practices that programmers tend to pick up and
imitate. If a company (or, more likely, individual programmer)
develops a practice and it catches on worldwide, and most of the
programmers using that language adopt it as one of the loose rules to
live by, the it can be considered a best practice for that language.
If a company comes up with a rule and the rule does not catch on
worldwide, then the rule is not a best practice for the language.

I've repeated myself in the 3 different posts now, which is perhaps
foolish on my part. I'll let this thread die now.

lkrubner@geocities.com (lawrence) wrote in message news:<da7e68e8.0309150933.30f97c2b@posting.google. com>...[color=blue]
> tony@marston-home.demon.co.uk (Tony Marston) wrote in message news:<7588a50f.0309110701.2b9ecd8f@posting.google. com>...> You are bringing up a[color=green][color=darkred]
> >> subject completely unrelated to what Andre was talking about. You[/color][/color]
> have[color=green][color=darkred]
> >> now written several posts and all of your posts have the same[/color][/color]
> theme.[color=green][color=darkred]
> >> In all of your posts you talk about bad managers.[/color]
> >
> >You are missing the point. All these managers produced development
> >standards and methodologies which were supposed to be examples of[/color]
> best[color=green]
> >practice but which were clearly no such thing. There are a multitude
> >of different methodologies and practices out there, and how many of
> >them are actually worth less than the paper they are written on? If
> >most of the standards that I have been exposed to have been rubbish,
> >then what percentage of the standards that I have not yet been[/color]
> exposed[color=green]
> >to will turn out to be just as much rubbish.[/color]
>
> At this point we're simply repeating ourselves. Your point was that
> there are bad managers in this world who promote bad practice and call
> it good practice. I understood you the first time you made that point,
> as well as the 2nd, 3rd, 4th, and 5th time you made that point. Once
> would have been enough.
>
> I pointed out that your point wasn't germane to the discussion because
> we weren't talking about what managers do, we were talking about what
> the programmers using a language do. If all the programmers using one
> language adopt some practice because it seems great then that becomes
> a "best practice" for the language.[/color]

But how do am I supposed to know what other programmers who are
outside of my current group do? In this situation my "masters" are my
immediate superiors at my place of work, not a group with whom I have
no contact whatsoever. My knowledge comes from two sources - what I am
taught by others and what I learn myself. So far the vast majority of
what I have been taught by others has turned out to be total crap. Why
should I not consider that what you are trying to teach me is also
total crap?
[color=blue]
> Look around and you'll see dozens
> of examples of this everyday. "Don't break encapsulation" is a good
> example of a "best practice".[/color]

Using public variables has got nothing to do with encapsulation. Read
http://www.javaworld.com/javaworld/j...psulation.html
and http://www.toa.com/pub/abstraction.txt
[color=blue]
>[/color]
As Andre said, these are guidelines, not[color=blue]
> hard rules, but everyone using a language usually is admonished to use
> the guideline when they can.[/color]

But I am not working to somebody else's second-rate rules, I am
creating my own rules.
[color=blue]
> As I said before, your examples of bad managers are entertaining, and
> I enjoyed reading them, but they are not what we are talking about.[/color]

They are closely related. You, and others like you keep using phrases
such as "everybody knows that..." and "it is common knowledge
that...". But you fail to realise that it is impossible to know what
everybody else knows. If two people tell me contradictory things, who
am I supposed to believe? If I read two articles which contradict each
other, which one am I supposed to believe?

It has been my experience that the only opinion I can trust is my own.
Somebody may present me with what they think is a good idea, but I
have to try it for myself to see if what they say is true. But unless
it works better than my current methodolgy I see no point in adipting
it. If somebody tells me that something is bad, but I have used it
successfully in the past without any problems then I have no choice
but to disbelieve them. If they are having problems then it must be
down to their own incompetence.
[color=blue]
> We
> are talking about those practices that programmers tend to pick up and
> imitate. If a company (or, more likely, individual programmer)
> develops a practice and it catches on worldwide, and most of the
> programmers using that language adopt it as one of the loose rules to
> live by, the it can be considered a best practice for that language.
> If a company comes up with a rule and the rule does not catch on
> worldwide, then the rule is not a best practice for the language.
>
> I've repeated myself in the 3 different posts now, which is perhaps
> foolish on my part. I'll let this thread die now.[/color]

You have still failed to answer the original question which started
this thread, or have given me any justification as to why certain
practices are wrong. "Everybody knows" is just not good enough, I want
to know the whys and the wherefores.

Tony Marston
http://www.tonymarston.net/

tony@marston-home.demon.co.uk (Tony Marston) wrote in message news:<7588a50f.0309160419.2f747d76@posting.google. com>...[color=blue]
> lkrubner@geocities.com (lawrence) wrote in message news:<da7e68e8.0309150933.30f97c2b@posting.google. com>...[color=green]
> > tony@marston-home.demon.co.uk (Tony Marston) wrote in message news:<7588a50f.0309110701.2b9ecd8f@posting.google. com>...> You are bringing up a[color=darkred]
> > >> subject completely unrelated to what Andre was talking about. You[/color][/color]
> have[color=green][color=darkred]
> > >> now written several posts and all of your posts have the same[/color][/color]
> theme.[color=green][color=darkred]
> > >> In all of your posts you talk about bad managers.
> > >
> > >You are missing the point. All these managers produced development
> > >standards and methodologies which were supposed to be examples of[/color][/color]
> best[color=green][color=darkred]
> > >practice but which were clearly no such thing. There are a multitude
> > >of different methodologies and practices out there, and how many of
> > >them are actually worth less than the paper they are written on? If
> > >most of the standards that I have been exposed to have been rubbish,
> > >then what percentage of the standards that I have not yet been[/color][/color]
> exposed[color=green][color=darkred]
> > >to will turn out to be just as much rubbish.[/color]
> >
> > At this point we're simply repeating ourselves. Your point was that
> > there are bad managers in this world who promote bad practice and call
> > it good practice. I understood you the first time you made that point,
> > as well as the 2nd, 3rd, 4th, and 5th time you made that point. Once
> > would have been enough.
> >
> > I pointed out that your point wasn't germane to the discussion because
> > we weren't talking about what managers do, we were talking about what
> > the programmers using a language do. If all the programmers using one
> > language adopt some practice because it seems great then that becomes
> > a "best practice" for the language.[/color]
>
> But how do am I supposed to know what other programmers who are
> outside of my current group do? In this situation my "masters" are my
> immediate superiors at my place of work, not a group with whom I have
> no contact whatsoever. My knowledge comes from two sources - what I am
> taught by others and what I learn myself. So far the vast majority of
> what I have been taught by others has turned out to be total crap. Why
> should I not consider that what you are trying to teach me is also
> total crap?[/color]

Most of us get a lot of info about other programmers from usenet
discussions like this one. Don't you?

[color=blue]
> You have still failed to answer the original question which started
> this thread, or have given me any justification as to why certain
> practices are wrong. "Everybody knows" is just not good enough, I want
> to know the whys and the wherefores.[/color]

According to Google, this thread didn't start with a question, it
started with Matty making a few observations about 00. You can see his
post at the top at this address:

http://groups.google.com/groups?hl=e...%26scoring%3Dd

lkrubner@geocities.com (lawrence) wrote in message news:<da7e68e8.0309161216.6fa2769e@posting.google. com>...[color=blue]
> tony@marston-home.demon.co.uk (Tony Marston) wrote in message news:<7588a50f.0309160419.2f747d76@posting.google. com>...[color=green]
> > lkrubner@geocities.com (lawrence) wrote in message news:<da7e68e8.0309150933.30f97c2b@posting.google. com>...[color=darkred]
> > > tony@marston-home.demon.co.uk (Tony Marston) wrote in message news:<7588a50f.0309110701.2b9ecd8f@posting.google. com>...> You are bringing up a
> > > >> subject completely unrelated to what Andre was talking about. You[/color][/color]
> have[color=green][color=darkred]
> > > >> now written several posts and all of your posts have the same[/color][/color]
> theme.[color=green][color=darkred]
> > > >> In all of your posts you talk about bad managers.
> > > >
> > > >You are missing the point. All these managers produced development
> > > >standards and methodologies which were supposed to be examples of[/color][/color]
> best[color=green][color=darkred]
> > > >practice but which were clearly no such thing. There are a multitude
> > > >of different methodologies and practices out there, and how many of
> > > >them are actually worth less than the paper they are written on? If
> > > >most of the standards that I have been exposed to have been rubbish,
> > > >then what percentage of the standards that I have not yet been[/color][/color]
> exposed[color=green][color=darkred]
> > > >to will turn out to be just as much rubbish.
> > >
> > > At this point we're simply repeating ourselves. Your point was that
> > > there are bad managers in this world who promote bad practice and call
> > > it good practice. I understood you the first time you made that point,
> > > as well as the 2nd, 3rd, 4th, and 5th time you made that point. Once
> > > would have been enough.
> > >
> > > I pointed out that your point wasn't germane to the discussion because
> > > we weren't talking about what managers do, we were talking about what
> > > the programmers using a language do. If all the programmers using one
> > > language adopt some practice because it seems great then that becomes
> > > a "best practice" for the language.[/color]
> >
> > But how do am I supposed to know what other programmers who are
> > outside of my current group do? In this situation my "masters" are my
> > immediate superiors at my place of work, not a group with whom I have
> > no contact whatsoever. My knowledge comes from two sources - what I am
> > taught by others and what I learn myself. So far the vast majority of
> > what I have been taught by others has turned out to be total crap. Why
> > should I not consider that what you are trying to teach me is also
> > total crap?[/color]
>
> Most of us get a lot of info about other programmers from usenet
> discussions like this one. Don't you?[/color]

But as there is SOOOOOOO much possible information out there how on
earth do you filter out the excellent from the excrement? Just because
somebody may write "I think everybody should do it THIS way" does not
mean that everybody will want to do it that way. There are too many
opinions, and many of them conflict with one another, so how do I know
which ones are right?

The short answer is that it is a matter of personal preference and
personal experience. I do what works for me, and you do what works for
you. But unless you can point out a genuine flaw in my methodology
(the phrase "I don't like it" does not qualify under these
circumstances) anything you have to say is mere opinion and can safely
be ignored.
[color=blue][color=green]
> > You have still failed to answer the original question which started
> > this thread, or have given me any justification as to why certain
> > practices are wrong. "Everybody knows" is just not good enough, I want
> > to know the whys and the wherefores.[/color]
>
> According to Google, this thread didn't start with a question, it
> started with Matty making a few observations about 00. You can see his
> post at the top at this address:
>[/color]

It was supposed to be a continuation of a thread started by me (see
http://groups.google.com/groups?dq=&...ing.google.com
) You can see his reference to the original thread in the title.

Tony Marston

On 17 Sep 2003 03:20:45 -0700, Tony Marston wrote:
[color=blue]
>But as there is SOOOOOOO much possible information out there how on
>earth do you filter out the excellent from the excrement?[/color]

talking to programmers you consider good, reading a good book once in
a while... and using your own judgement, of course. i find that while
not everybody agrees on everything, there is a good deal i can agree
on even with people i generally disagree with. just separate the
issues.
[color=blue]
>It was supposed to be a continuation of a thread started by me (see
>http://groups.google.com/groups?dq=&...ing.google.com
>) You can see his reference to the original thread in the title.[/color]

it seems to me, from reading the first few messages of the thread,
that the "community" largely agreed that your approach is adequate.

so there were some that got confused about your approach and didn't
think it was a clean oo/mvc implementation -- which you probably
didn't intend it to be in the first place. what's the big deal?

Gerhard Fiedler <me@privacy.net> wrote in message news:<ceogmvg8hdqq0eg5nrt70p6rkj62u1d54f@4ax.com>. ..[color=blue]
> On 17 Sep 2003 03:20:45 -0700, Tony Marston wrote:
>[color=green]
> >But as there is SOOOOOOO much possible information out there how on
> >earth do you filter out the excellent from the excrement?[/color]
>
> talking to programmers you consider good, reading a good book once in
> a while... and using your own judgement, of course. i find that while
> not everybody agrees on everything, there is a good deal i can agree
> on even with people i generally disagree with. just separate the
> issues.
>[color=green]
> >It was supposed to be a continuation of a thread started by me (see
> >http://groups.google.com/groups?dq=&...ing.google.com
> >) You can see his reference to the original thread in the title.[/color]
>
> it seems to me, from reading the first few messages of the thread,
> that the "community" largely agreed that your approach is adequate.[/color]

Some agreed with my approach, yet those who disagreed kept arguing
that "everybody knew" that my approach was wrong.
[color=blue]
> so there were some that got confused about your approach and didn't
> think it was a clean oo/mvc implementation -- which you probably
> didn't intend it to be in the first place. what's the big deal?[/color]

There are some people out there who class themselves as "experts" and
who try to tell me that what I am doing is "unacceptable", but instead
of giving me solid reasons, such as genuine problems that I have
overlooked, they just say "everybody knows ..." or "it is common
knowledge ..." which turns out to be nothing more than ill-informed
opinion.

Take for example the phrase "everybody knows that using public
variables breaks encapsulation and is therefore stupid, so they agree
not to do it". This statement is seriously flawed because it assumes
that data hiding (by not using public variables) is the same as
encapsulation, which it is not. If the eason for having the rulke is
flawed, then the rule itself is flawed and can be ignored.

So, instead of getting constructive responses to my original query I
have ended up by exposing a lot of these "experts" as nothing more
than charalatans and cowboys.

Tony Marston
http:/www.tonymarston.net/

tony@marston-home.demon.co.uk (Tony Marston) wrote in message[color=blue]
> But as there is SOOOOOOO much possible information out there how on
> earth do you filter out the excellent from the excrement? Just because
> somebody may write "I think everybody should do it THIS way" does not
> mean that everybody will want to do it that way. There are too many
> opinions, and many of them conflict with one another, so how do I know
> which ones are right?[/color]

I think Andre was making the assumption, and certainly I do, that if
the vast majority of some community of programmers start following a
given practice, then there must be something good about that practice.
For instance, "Don't break encapsulation" is a general rule that most
programmers try to follow most of the time. Therefore it can properly
be considered a "best practice", because there is a wide consensus
that most of the time it is a good idea.

On 18 Sep 2003 00:14:10 -0700, Tony Marston wrote:
[color=blue][color=green]
>> so there were some that got confused about your approach and didn't
>> think it was a clean oo/mvc implementation -- which you probably
>> didn't intend it to be in the first place. what's the big deal?[/color]
>
>There are some people out there who class themselves as "experts" and
>who try to tell me that what I am doing is "unacceptable", but instead
>of giving me solid reasons, such as genuine problems that I have
>overlooked, they just say "everybody knows ..." or "it is common
>knowledge ..." which turns out to be nothing more than ill-informed
>opinion.[/color]

i just felt that the discussion was getting unproductive... :)

[color=blue]
>Take for example the phrase "everybody knows that using public
>variables breaks encapsulation and is therefore stupid, so they agree
>not to do it".[/color]

the way i understand that "rule" is that it is a good idea to be very
careful with public variables. especially when designing modules that
are supposed to be used together with other code. nothing more,
nothing less. and if there are no tradeoffs, i tend to avoid them. but
often there are tradeoffs, and then the priorities decide. and that is
probably how most tend to see it, in the sense of the discussed "best
practice". but then, there always seem to be some religious leaders...
:)

"Gerhard Fiedler" <me@privacy.net> wrote in message
news:r3tlmv8cb717cf05v6ioj6p9eie37cek85@4ax.com...[color=blue]
> On 18 Sep 2003 00:14:10 -0700, Tony Marston wrote:
>[color=green]
> >Take for example the phrase "everybody knows that using public
> >variables breaks encapsulation and is therefore stupid, so they agree
> >not to do it".[/color]
>
> the way i understand that "rule" is that it is a good idea to be very
> careful with public variables. especially when designing modules that
> are supposed to be used together with other code. nothing more,
> nothing less. and if there are no tradeoffs, i tend to avoid them. but
> often there are tradeoffs, and then the priorities decide. and that is
> probably how most tend to see it, in the sense of the discussed "best
> practice". but then, there always seem to be some religious leaders...
> :)[/color]

IMHO standards should educate rather than dictate. If there are problems
with a command or facility in a language or methodology then rather than
dictating "do not use this under any circumstances" they should educate by
saying "if you use this in *this* way there could be such-and-such problem".
I have come across too many examples of rules which fall apart under
scrutiny, so unless they are properly qualified and quantified my suspicions
are immediately aroused.

I sometimes find that some rules are carried from one group to another but
the logic behind them gets dropped or misquoted, just as in "Chinese
whispers", so you end up with people who follow rules religiously without
fully understanding the history behind them. Quite often if you knew the
history you would abandon the rule.

Here endeth the lesson.

Tony (don't applaud, just throw money) Marston
http://www.tonymarston.net/

"Tony Marston" <tony@NOSPAM.demon.co.uk> wrote in message news:<bkh7kj$s06$1$830fa17d@news.demon.co.uk>...[color=blue]
> IMHO standards should educate rather than dictate. If there are problems
> with a command or facility in a language or methodology then rather than
> dictating "do not use this under any circumstances" they should educate by
> saying "if you use this in *this* way there could be such-and-such problem".
> I have come across too many examples of rules which fall apart under
> scrutiny, so unless they are properly qualified and quantified my suspicions
> are immediately aroused.[/color]

Well, it seems you've had some bad experiences with arrogant managers,
which may explain the vehemence of your responses. Still, it seems in
the end we are all in agreement on this issue of best practice. The
rules are there as guidelines, they are not meant to be applied in
every circumstance.

lawrence wrote:

[color=blue]
> Well, it seems you've had some bad experiences with arrogant managers,
> which may explain the vehemence of your responses. Still, it seems in
> the end we are all in agreement on this issue of best practice. The
> rules are there as guidelines, they are not meant to be applied in
> every circumstance.[/color]

You must have missed the start of the thread then Lawrence!

The main thrust of much of the original discussion, and that which
followed, was the question

"What consitutes good/badd OOP?"

Although you might expect this to involve discussions about things
like encapsulation, good design allowing code-reuse, consistent
interfaces, reliable software, etc, a lot of it has come down to
nitty-gritty aspects of implementation, and whether "code that does
foo" should be allowed to coexist in an object with "code that does
bar", and whether function X belongs in the same category as function
Y, etc...

Everyone seems to agree that there are many different ways of coding,
and many different ways of coding *well*, but a lot of it seems to
have come down to "four legs good, 2 legs better".

One point on which I agree very strongly with Tony, is that just because
someone says "You should implement this using MVC principles", it doesn't
mean that MVC will automatically produce good software, or that taking a
different route will produce bad software. MVC is just a philosophy of
code design - people tend to go for UML diagrams for modelling now, just
as they used to go for the SSADM school of thought in the past. It doesn't
mean that one method is better than the other, they're just *different* -
there is no such thing as good or bad OO design. Code is good if it
works.

(my thoughts...)

Matt

All-Out Flamewar... (was good/bad OOPS)

re: All-Out Flamewar... (was good/bad OOPS)

re: All-Out Flamewar... (was good/bad OOPS)

re: All-Out Flamewar... (was good/bad OOPS)

re: All-Out Flamewar... (was good/bad OOPS)

re: All-Out Flamewar... (was good/bad OOPS)

re: All-Out Flamewar... (was good/bad OOPS)

re: All-Out Flamewar... (was good/bad OOPS)

re: All-Out Flamewar... (was good/bad OOPS)

re: All-Out Flamewar... (was good/bad OOPS)

re: All-Out Flamewar... (was good/bad OOPS)

re: All-Out Flamewar... (was good/bad OOPS)

re: All-Out Flamewar... (was good/bad OOPS)

re: All-Out Flamewar... (was good/bad OOPS)

re: All-Out Flamewar... (was good/bad OOPS)

re: All-Out Flamewar... (was good/bad OOPS)

re: All-Out Flamewar... (was good/bad OOPS)

re: All-Out Flamewar... (was good/bad OOPS)

re: All-Out Flamewar... (was good/bad OOPS)

re: All-Out Flamewar... (was good/bad OOPS)

re: All-Out Flamewar... (was good/bad OOPS)

re: All-Out Flamewar... (was good/bad OOPS)

re: All-Out Flamewar... (was good/bad OOPS)

re: All-Out Flamewar... (was good/bad OOPS)

re: All-Out Flamewar... (was good/bad OOPS)

Similar PHP bytes

/bytes/development

/bytes/it

/bytes/about