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
24  3455 
matty: Look at Windows 9x. Big messy mixture of functional and OO coding,
varying APIs, inconsistent, bug-ridden, often unstable and unpredictable.
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.
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.
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.
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?
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.
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.
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
<bh**********@maud.ifi.uio.no>,"André Næss"
<an*********************@ifi.uio.no> wrote: [...] 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 ]
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" <an*********************@ifi.uio.no> wrote in message
news:bh**********@maud.ifi.uio.no... matty:
Look at Windows 9x. Big messy mixture of functional and OO coding,
varying APIs, inconsistent, bug-ridden, often unstable and
unpredictable.
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.
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.
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.
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?
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:
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.
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.
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".
B) I'll better listen to the masters if I want to be an expert in this
language.
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".
Guess what approach I prefer.
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.
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.
I agree entirely.
Best-practices always apply within a
context, nobody ever said that you should always use them,
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".
although newbies
tend to do that. But they are best-practices for a *reason*.
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 <an*********************@ifi.uio.no> wrote in message news:<bj**********@maud.ifi.uio.no>... Tony Marston:
<snip> Programming is an art, not a science
Indeed.
, 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:
Certainly. But in every language there are things you simply should avoid.
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?
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.
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.
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.
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*.
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.
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.
What is not acceptable? That the code was unreadable or that it wasn't
accepted due to it's unmaintainable nature?
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".
> 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?
They are written down and published of course, through the WWW, through
books, through Usenet etc.
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>
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.
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.
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.
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.
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.
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>
We are not talking about rules in such a strict sense. We've been talking
about common practices,
But what is common practice to one group may not be common practice to
another. So how do I know which group to follow?
things that developers have discovered during
their many years of trial and error.
But different groups of programmers have discovered different
solutions to similar problems. So how do I know which group to follow?
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.
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?
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.
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.
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>
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.
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.
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.
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.
Those are merely style issues. While they are certainly important, I don't
think they are that relevant to this discussion.
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.
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.
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?
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.
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",
But saying "This is better because it leads to better maintainability/faster
code/fewer bugs" presumably isn't.
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.
An individual's creativity must
be allowed to shine otherwise everything will remain the same and
there will never be any progress.
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.
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.
Reinventing the wheel doesn't exactly generate much progress.
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" <to**@NOSPAM.demon.co.uk> wrote in message news:<bi*******************@news.demon.co.uk>...> 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?
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 <an*********************@ifi.uio.no> wrote in message Have these standards been published anywhere?
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 :)
What is
the level of competence of the authors? What is their justification for
their "rules"?
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.
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.
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.
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.
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.
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.
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".
Some examples would be very enlightening.
Best-practices always apply within a
context, nobody ever said that you should always use them,
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".
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
André N?ss <an*********************@ifi.uio.no> wrote in message 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.
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? to**@marston-home.demon.co.uk (Tony Marston) wrote in message news:<75**************************@posting.google. com>... Andr¨¦ N?ss <an*********************@ifi.uio.no> wrote in message news:<bj**********@maud.ifi.uio.no>... Tony Marston:
Certainly. But in every language there are things you simply should avoid.
Then take the matter up with the authors of those languages.
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.
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".
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.
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?
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.
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.
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.
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*.
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.
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.
What is not acceptable? That the code was unreadable or that it wasn't
accepted due to it's unmaintainable nature?
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".
> > 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?
They are written down and published of course, through the WWW, through
books, through Usenet etc.
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>
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.
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.
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.
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.
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.
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>
> We are not talking about rules in such a strict sense. We've been talking
> about common practices,
But what is common practice to one group may not be common practice to
another. So how do I know which group to follow?
things that developers have discovered during
> their many years of trial and error.
But different groups of programmers have discovered different
solutions to similar problems. So how do I know which group to follow?
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.
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?
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.
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.
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>
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.
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.
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.
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.
Those are merely style issues. While they are certainly important, I don't
think they are that relevant to this discussion.
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.
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.
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?
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.
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",
But saying "This is better because it leads to better maintainability/faster
code/fewer bugs" presumably isn't.
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.
An individual's creativity must
be allowed to shine otherwise everything will remain the same and
there will never be any progress.
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.
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.
Reinventing the wheel doesn't exactly generate much progress.
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/ lk******@geocities.com (lawrence) wrote in message news:<da**************************@posting.google. com>... André Næss <an*********************@ifi.uio.no> wrote in message
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.
I think Andre sums it up well. The legal equivalent would be English
Common Law, or perhaps, in general, case law.
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.
A civil society will
generate standards with input from every group in the community.
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.
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.
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.
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.
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/ lk******@geocities.com (lawrence) wrote in message news:<da**************************@posting.google. com>... to**@marston-home.demon.co.uk (Tony Marston) wrote in message news:<75**************************@posting.google. com>... Andr¨¦ N?ss <an*********************@ifi.uio.no> wrote in message news:<bj**********@maud.ifi.uio.no>... Tony Marston:
Certainly. But in every language there are things you simply should avoid.
Then take the matter up with the authors of those languages.
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.
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.
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".
Why are you calling this manager a master? Was he internationally
recognized as such?
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¡±.
Did the worldwide community of COBOL programmers
follow his lead and give up using the COMPUTE verb?
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.
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.
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.
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.
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.
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.
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.
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.
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?
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 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.
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.
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: 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.
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.
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 <an*********************@ifi.uio.no> wrote in message news:<bj**********@maud.ifi.uio.no>... Tony Marston:
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.
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.
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 :)
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.
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
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: The fact that managers are clueless when it comes to technology is news to
none :)
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.
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.)
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.
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 :)) to**@marston-home.demon.co.uk (Tony Marston) wrote in message news:<75**************************@posting.google. com>...> 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.
You are missing the point. All these managers produced development
standards and methodologies which were supposed to be examples of
bestpractice 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
exposedto 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. 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. lk******@geocities.com (lawrence) wrote in message news:<da**************************@posting.google. com>... to**@marston-home.demon.co.uk (Tony Marston) wrote in message news:<75**************************@posting.google. com>...> 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.
You are missing the point. All these managers produced development
standards and methodologies which were supposed to be examples of
bestpractice 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
exposedto 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.
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?
Look around and you'll see dozens
of examples of this everyday. "Don't break encapsulation" is a good
example of a "best practice".
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
As Andre said, these are guidelines, not hard rules, but everyone using a language usually is admonished to use
the guideline when they can.
But I am not working to somebody else's second-rate rules, I am
creating my own rules.
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.
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.
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.
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/ to**@marston-home.demon.co.uk (Tony Marston) wrote in message news:<75**************************@posting.google. com>... lk******@geocities.com (lawrence) wrote in message news:<da**************************@posting.google. com>... to**@marston-home.demon.co.uk (Tony Marston) wrote in message news:<75**************************@posting.google. com>...> 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.
You are missing the point. All these managers produced development
standards and methodologies which were supposed to be examples of bestpractice 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 exposedto 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.
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?
Most of us get a lot of info about other programmers from usenet
discussions like this one. Don't you?
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.
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 lk******@geocities.com (lawrence) wrote in message news:<da**************************@posting.google. com>... to**@marston-home.demon.co.uk (Tony Marston) wrote in message news:<75**************************@posting.google. com>... lk******@geocities.com (lawrence) wrote in message news:<da**************************@posting.google. com>... to**@marston-home.demon.co.uk (Tony Marston) wrote in message news:<75**************************@posting.google. com>...> 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.
>
>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.
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.
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?
Most of us get a lot of info about other programmers from usenet
discussions like this one. Don't you?
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. 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.
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:
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: But as there is SOOOOOOO much possible information out there how on
earth do you filter out the excellent from the excrement?
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.
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.
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:<ce********************************@4ax.com>. .. On 17 Sep 2003 03:20:45 -0700, Tony Marston wrote:
But as there is SOOOOOOO much possible information out there how on
earth do you filter out the excellent from the excrement?
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.
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.
it seems to me, from reading the first few messages of the thread,
that the "community" largely agreed that your approach is adequate.
Some agreed with my approach, yet those who disagreed kept arguing
that "everybody knew" that my approach was wrong.
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?
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/ to**@marston-home.demon.co.uk (Tony Marston) wrote in message 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?
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: 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?
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.
i just felt that the discussion was getting unproductive... :)
Take for example the phrase "everybody knows that using public
variables breaks encapsulation and is therefore stupid, so they agree
not to do it".
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:r3********************************@4ax.com... On 18 Sep 2003 00:14:10 -0700, Tony Marston wrote:
Take for example the phrase "everybody knows that using public
variables breaks encapsulation and is therefore stupid, so they agree
not to do it".
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...
:)
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" <to**@NOSPAM.demon.co.uk> wrote in message news:<bk*******************@news.demon.co.uk>... 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.
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: 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.
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 This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: chirs |
last post by:
Hi,
What does all mean in if(document.all)? I could not find an object
called all in the page.
Thanks
|
by: Chris Becker |
last post by:
I have the following query:
SELECT Month, Sum(Hits) AS Hits FROM tblHits GROUP BY Month ORDER BY
Month
Unfortunately it only returns rows for months that have data assigned
to them.
How...
|
by: InvisibleMan |
last post by:
Hi,
Thanks for any help in advance... Okay, I have the JS listed
below that calls for the display of the (DIV) tag... cookie
function not included, as don't feel its necessary but you'll
get the...
|
by: peter |
last post by:
I use the click-to-expand menu at
http://javascript.internet.com/navigation/click-to-expand-menu.html
This works fine, but is there a way to expand or collapse all the
menus?
An example of how...
|
by: Scott Marquardt |
last post by:
Consider a table that holds Internet browsing history for users/machines,
date/timed to the minute. The object is to tag all times that are separated
by previous and subsequent times by x number of...
|
by: piet |
last post by:
Is it possible to add an option ALL in the ist of a combobox that get its
values from a table?
Example:
in the combobox are the items from the table "days": monday, th....
The chosen value...
|
by: Zhiqiang Ye |
last post by:
Hi, All
I am reading FAQ of this group. I have a question about this:
http://www.eskimo.com/~scs/C-faq/q7.31.html
It says:
"
p = malloc(m * n);
memset(p, 0, m * n);
The zero fill is...
|
by: Steve R. Hastings |
last post by:
So, Python 2.5 will have new any() and all() functions.
http://www.python.org/dev/peps/pep-0356/
any(seq) returns True if any value in seq evaluates true, False otherwise.
all(seq) returns...
|
by: anurag |
last post by:
hey can anyone help me in writing a code in c (function) that prints
all permutations of a string.please help
|
by: wugon.net |
last post by:
question: db2 LUW V8 UNION ALL with table function month() have bad
query performance
Env:
db2 LUW V8 + FP14
Problem :
We have history data from 2005/01/01 ~ 2007/05/xx in single big...
|
by: lllomh |
last post by:
Define the method first
this.state = {
buttonBackgroundColor: 'green',
isBlinking: false, // A new status is added to identify whether the button is blinking or not
}
autoStart=()=>{
|
by: DJRhino |
last post by:
Was curious if anyone else was having this same issue or not....
I was just Up/Down graded to windows 11 and now my access combo boxes are not acting right. With win 10 I could start typing...
|
by: isladogs |
last post by:
The next Access Europe meeting will be on Wednesday 4 Oct 2023 starting at 18:00 UK time (6PM UTC+1) and finishing at about 19:15 (7.15PM)
The start time is equivalent to 19:00 (7PM) in Central...
|
by: Aliciasmith |
last post by:
In an age dominated by smartphones, having a mobile app for your business is no longer an option; it's a necessity. Whether you're a startup or an established enterprise, finding the right mobile app...
|
by: NeoPa |
last post by:
Hello everyone.
I find myself stuck trying to find the VBA way to get Access to create a PDF of the currently-selected (and open) object (Form or Report).
I know it can be done by selecting :...
|
by: NeoPa |
last post by:
Introduction
For this article I'll be using a very simple database which has Form (clsForm) & Report (clsReport) classes that simply handle making the calling Form invisible until the Form, or all...
|
by: Teri B |
last post by:
Hi, I have created a sub-form Roles. In my course form the user selects the roles assigned to the course.
0ne-to-many. One course many roles.
Then I created a report based on the Course form and...
|
by: isladogs |
last post by:
The next Access Europe meeting will be on Wednesday 1 Nov 2023 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM)
Please note that the UK and Europe revert to winter time on...
|
by: GKJR |
last post by:
Does anyone have a recommendation to build a standalone application to replace an Access database? I have my bookkeeping software I developed in Access that I would like to make available to other...
| |
