SitePoint Sponsor |
|
User Tag List
Results 151 to 175 of 190
-
May 23, 2006, 16:48 #151Off Topic:
Originally Posted by lastcraft
If you didn't mean that, then ignore this.
-
May 23, 2006, 17:32 #152
- Join Date
- Aug 2003
- Location
- Toronto
- Posts
- 300
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by kyberfabrikken
So what is a good equation? Well, for one, they tend to express something complicated in a concise and often simple way (if you are versed in the terminology) and they often open up new avenues of thought (ie: make other statements possible). Yet one can draw definitions like that up until the cows come home. You can't really define it just as you can't really define what makes a good piece of art (yet when we go to the museum we can readily appreciate what is there). TAOP is the closest thing I know to a work that can even begin to shed light on the matter of good code and yet despite all its volumes and the precious wisdoms it distills, it can really only impart the feeling of the beauty that can be code. (yes, there are other great works too)
It occurs to me there are plenty of "ugly code sites" on the net. Maybe a museum of beautiful code is what is really needed. IOW, instead of looking always at the bad, we should also look at the good. At least then we can admire and be inspired even if we can't quite exactly say why or how.
best,
-
May 23, 2006, 18:16 #153
- Join Date
- Sep 2003
- Location
- Glasgow
- Posts
- 1,690
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by lastcraft
-
May 23, 2006, 19:09 #154
- Join Date
- Apr 2003
- Location
- London
- Posts
- 2,423
- Mentioned
- 2 Post(s)
- Tagged
- 0 Thread(s)
Hi...
Originally Posted by McGruff
Whilst I think TDD does a lot to sort out the mechanics, and the tight cycle is a great learning tool, I don't think it's enough. Once your tests pass, you still have to refactor. I don't think "remove duplication" is enough in itself either. Deciding if code is really common can be a rather subtle problem.
I can see why Martin Fowler went for the "worst practice" list (code smells) in the refactoring book. It's the same ontology as a military campaign or firefighting. There is no correct way to win a battle or fight a fire, but there are well known stupid things you can do.
So what makes the stupid things stupid?
yours, MarcusMarcus Baker
Testing: SimpleTest, Cgreen, Fakemail
Other: Phemto dependency injector
Books: PHP in Action, 97 things
-
May 23, 2006, 20:08 #155
- Join Date
- Nov 2002
- Posts
- 841
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Stupid things are stupid because they make the program harder to change, harder to understand and harder to get right.
-
May 23, 2006, 22:34 #156
- Join Date
- May 2003
- Location
- The Netherlands
- Posts
- 391
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by lastcraft
Maintainability
Reusability
Consistency
Robustness
Flexibility
I shall no doubt forget something, but I can tell you that if I see code that copes with all the above, I'm already a happy man.There’s more than one way to skin a cat.
-
May 24, 2006, 00:03 #157
- Join Date
- May 2005
- Location
- Holland!
- Posts
- 852
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Good code is like the perfect woman.
Hard to define, but it is love at first "site"
There is no perfect wo(man), .... nobody = perfect...Business as usual is off the menu folks, ...
-
May 24, 2006, 01:36 #158
- Join Date
- Jan 2004
- Location
- Oslo, Norway
- Posts
- 894
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by jayboots
Programming is one of the most difficult branches of applied mathematics; the poorer mathematicians had better remain pure mathematicians.Originally Posted by jayboots
That won't happen tomorrow, but at least we can discuss the prerequisites for a project like that. And it seemed to me that the most useful starting point would be to have some agreement on how to tell the difference between good and bad code.Dagfinn Reiersøl
PHP in Action / Blog / Twitter
"Making the impossible possible, the possible easy,
and the easy elegant" -- Moshe Feldenkrais
-
May 24, 2006, 01:52 #159
- Join Date
- May 2005
- Posts
- 255
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by sweatje
Polymorphism exists for the purpose of code reusability while retaining (the illusion of...) "type safety". Type safety is only truly important in languages where you're dealing with memory directly, anyway. Dynamically typed languages carry their type information around with them, so the big worries about type safety go out the window (you'll always have the correct size, always know what members are available, etc.)
If you want to argue the generic definition of polymorphism being the simple concept of reusing the same code on multiple pieces of data, I'd agree with the sentiment that it's useful, but in that case it has absolutely nothing to do with OOP since it's just as easy to write polymorphic procedural code as it is to write OO code, you just get the marginal benefit of being able to segment the code a little better (although in languages like php, even that's mostly a non-issue since you can go as far as putting implementations for different data types into different files, if you want).
What I argue as being a crutch is polymorphism in the atrocious whitelisting capacity that it exists in C++ and Java.
Before I show any examples, I want to point out that Ruby is the only dynamic language I know. I imagine other dynamic languages support duck-typing as well, but I'm not positive.
============================================
Now, this has gone entirely off-topic. My original point was that OO vs. procedural code has absolutely zero impact on the relative quality of any given piece of code. Quite simply, the benefits afforded by OO are almost universally offset by the increased complexity, and as such the majority of people don't get it right, and wind up producing lower quality code than they would had they simply used a clean procedural interface instead.
So what makes the stupid things stupid?
Flexibility
Edsger Dijkstra had this to say about it in 1975 (http://www.cs.virginia.edu/~evans/c...ngs/ewd498.html):
Besides a mathematical inclination, an exceptionally good mastery of one's native tongue is the most vital asset of a competent programmer.
-
May 24, 2006, 04:26 #160
- Join Date
- Jun 2004
- Location
- Copenhagen, Denmark
- Posts
- 6,157
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by jayboots
Originally Posted by jayboots
Originally Posted by dagfinn
-
May 24, 2006, 04:34 #161
- Join Date
- Jun 2004
- Location
- Copenhagen, Denmark
- Posts
- 6,157
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by Etnu
-
May 24, 2006, 05:48 #162
- Join Date
- Nov 2001
- Location
- Bath, UK
- Posts
- 2,498
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by Etnu
"Pythonic programming style that determines an object's type by inspection of its method or attribute signature rather than by explicit relationship to some type object ("If it looks like a duck and quacks like a duck, it must be a duck.") By emphasizing interfaces rather than specific types, well-designed code improves its flexibility by allowing polymorphic substitution."
Duck typing is a form of polymorphism, it isn't polymorphism vs duck typing because duck typing is polymorphism.
I think what you're really talking about is the distinction between explicit static interface declarations, and informal "it just works" dynamic duck typing.
In this case, you're perfectly right, declaring explicit interfaces isn't nearly as useful in dynamic languages as it is in static languages, because static languages don't compile without it.
In that vain, I'd say the first thing to look for in good code, is that it compiles/runs without error warnings
DouglasHello World
-
May 24, 2006, 06:44 #163
- Join Date
- Sep 2003
- Location
- Glasgow
- Posts
- 1,690
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by Etnu
Polymorphism just means that a number of different types all implement the same interface. The type is irrelevant - that's the whole point. In OOP different types can be hidden behind a common interface. In procedural you're passing around data which isn't encapsulated by anything. You'll have to apply different functions to different types. Bang goes polymorphism.
Originally Posted by Etnu
-
May 24, 2006, 07:01 #164
- Join Date
- Nov 2002
- Posts
- 841
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by Galo
Along the way, we can also imagine some potential changes. If the code would react well to potential changes we have in mind, we consider it good. If it wouldn't, we consider it bad.
We also consider standards and best practices. If the code conforms to these, we consider it good and if it doesn't we consider it bad. Since the more of these we know, the less likely that any given piece of code conforms, maybe the more you know the more everyone (else's) code is bad.
For the most part, these are subjective and situational measures.
-
May 24, 2006, 07:12 #165
- Join Date
- Jan 2004
- Location
- Oslo, Norway
- Posts
- 894
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by Etnu
EDIT: BTW, the phrase "textbook logical fallacy" could be mistaken for an appeal to authority.
-
May 24, 2006, 07:46 #166
- Join Date
- Apr 2003
- Location
- London
- Posts
- 2,423
- Mentioned
- 2 Post(s)
- Tagged
- 0 Thread(s)
Hi...
Originally Posted by Selkirk
.
You see it really identifies the problem it is trying to solve: a startup attempting a rapid breakthrough into a mass market. Ookles has some nice features, such as assuming a replication environment from the start. It assumes sessions and the like are on separate DBs, so it's a multiple connection environment (no Singleton connection objects). They know the GUI is going to change a lot, so they've given free reign to the AJAX guys and other wise kept out of the way. They keep most of the data as blobs (it's for data sharing on the net), and so don't need a flexible storage model. And so on. It's a clever solution, given the problem space.
Someone said that design and code quality were the same thing. Well, I say look at Ookles and face a contradiction. It's more subtle than that.
So maybe we need "good in a certain way" as a criteria. The design goals should sit right next to the solution. Both should be enscribed on the plaque in the good code museum.
yours, MarcusMarcus Baker
Testing: SimpleTest, Cgreen, Fakemail
Other: Phemto dependency injector
Books: PHP in Action, 97 things
-
May 24, 2006, 07:49 #167
- Join Date
- Sep 2003
- Location
- Glasgow
- Posts
- 1,690
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by lastcraft
As Selkirk said, one of the stupid things to do is to make things harder to change. I'd much rather have a less than perfect but fully tested app than a perfect one with no tests. The latter is a beautiful statue: I can't do anything with it. With tests, all the machinery is in place to knock it into shape - any shape. At any given moment it might be better or worse but fluidity is more important to code quality than some kind of static perfection. Both are good but first you've got to get through the rapids in one piece.
-
May 24, 2006, 08:33 #168
- Join Date
- Aug 2005
- Posts
- 986
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
I think it is impossible (or VERY hard, especially in impure languages) to prove that a certain piece of code that passes a unit test is in fact the shortest code possible.
The simplest solution is often the shortest (not counted in lines, but code elements), but not always.
Good code is the most straightforward solution for a problem. That doesn't involve objects often.
-
May 24, 2006, 09:31 #169
And sometimes the most straightforward solution to a problem can still be very complex.
-
May 24, 2006, 09:59 #170
- Join Date
- Jan 2003
- Posts
- 5,748
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Good code is something which tells a story... In most cases this is the domain; If you can grab an understanding of the domain purely from the code and nothing more, then you are onto something, otherwise why bother?
-
May 24, 2006, 10:04 #171
- Join Date
- Oct 2004
- Location
- Worcester
- Posts
- 138
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
The definition of good code also depends on the problem the code is solving.
Personally I think good code is code that I can understand what it does and why it does it in that way. It gets bonus points for being easily modifiable to the new definition of the problem that the client has come up with!
-
May 24, 2006, 10:34 #172
- Join Date
- Jul 2002
- Location
- Dallas, TX
- Posts
- 2,900
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by akrabat
At some point you can strip away all the application-specific baggage of a project and objectively analyze the implementation, which I believe is the crux of this discussion. I'm not saying the definition or even recognition "good code" is entirely unconditional, but you have to adopt a purist perspective at some point or you'll abstract your assessment into a much weaker critique than it should be.
-
May 24, 2006, 10:41 #173
- Join Date
- Aug 2003
- Location
- Toronto
- Posts
- 300
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
lastcraft brought up a good point: context is very important. This extends to several areas: "good code" in the case of a framework is different than "good code" in the case of a specific method which is different again than "good code" in the case of an industrial embedded application which is again different than "good code" for... well, the list goes on.
To make it clearer with an arbitrary example, a really elegant and optimized (and finalized!) search algorithm has different criteria for "good" than, say, an order processing pipeline executor that must meet changing business needs over-time.
We ought be careful when we say things like "good code is maliable", "good code is efficient", etc, because without context any of those sorts of statements can be correct or not.
-
May 24, 2006, 11:34 #174
- Join Date
- Jan 2006
- Location
- Norway
- Posts
- 18
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by Galo
Altough my poor excuse of a joke wasn't as successfull as i thought it would be, it still describe what I wanted to express:
What we or rather you, since I haven't yet contributed, are trying to define is an idea that will differ from project to project and person to person. My idea of the "perfect" woman is probably not the same as yours, which of course is a good thing. Applied to the world of programming, "My idea" must be understood as one projects idea and as "jayboots" argued: Good code for one projects isn't automatically good code for another
Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away.
~Antoine de Saint-Exupéry
In reality what Antoine de Saint-Exupéry is describing is the process of refactoring. However in the search of perfection I might float away from the ground named reality. Never the less by using that principle on the arguments used in this thread, I believe you have defined a few basic definitions which are language and project independent for good code:
- Readable - Well formated, and esthetically pleasing
- Commented - Describes a process which otherwise might cause confusion
- Understandable - The applications flow is easy to follow
Likewise there exists ideas that a newcomer to the world of programming might misunderstand as a mean to automatically transform their code into good code .
- Design patterns - One of many ways to solve a problem, but what if the problem is a result of bad code.
- OOP vs Prosedural, Java VS Fortran - It doesn't matter if you drive a Porsche or a Ferrari, you might still crash.
Shifting the focus back to my original joke; defining good code is like defining the perfect partner. We usually share a few fundamental common rules, it is what we wrap around those that separates us.
As a finally observation it is interesting to note the difference between the infamous(?) PHP forum software that isn't an utter disgrace? and this one. Notice how much easier it is to pinpoint and agree upon what bade code is.
Edit
Spelling, etcLast edited by Fjoggen; May 24, 2006 at 13:59.
-
May 24, 2006, 11:46 #175
- Join Date
- May 2002
- Location
- Gent, Belgium
- Posts
- 284
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by DougBTX
By external quality factors, I mean desirable qualities of a software system that are visible to the client/constituent and the end users of that software system. These are the elements that will determine the amount of satisfaction experienced in using that system.
There are a bunch of those factors, what follows is a list of (imho) the most important ones:
- Correctness: This must be, without a doubt, the most important one; If a system doesn't do what it is specified to do, then it is of no use.
- Robustness: The agility of the system to react in an appropriate way to exceptional circumstances
- Extensibility: How easy the system can adapt to changes in the specifications
- Reusability: The degree to which parts of a software system can be reused in the construction of other software systems.
- Compatibility: How easy it is to combine software systems with eachother.
- Efficiency: The degree to which the system treats the resources at it's disposal in an economical way. (This can also be a subdivision of correctness, for example in real-time systems)
- Portability: How easy it is to configure the system to run in different environments
- Ease-of-use: How much effort an end user has to put in to use the system in executing their tasks.
- Functionality: Reflects the functional possibilities of a system
- Punctuality: The degree to which a software system is released when (or before) the users need it.
- Verifiability: How convenient it is to build acceptance procedures, test data and -procedures to trace errors when verifying and validating the system
- Integrity: The degree to which certain areas of the system (program and data) are protected to unauthorized access or modification.
- Economical factor: The degree to which a system is delivered within the budget.
It is simply impossible to maximize all these factors, because some have a negative impact on others:
Integrity/Ease-of-use, Functionality/Economical factor, Efficiency/Portability, Extensibility/Punctuality, ...
So to determine whether or not the software system (of which our code is a part) is 'good' (of high quality), it is very important to carefull weigh these factors against eachother and the desires of the stakeholders. Of course, correctness must always be the most important one.
There are practices that help in maximalizing certain external quality factors: for example; Unit and acceptance testing will augment Verifiability, maybe robustness. Agile methodologies could maximize Punctuality, perhaps the Economical factor, and so on...
Then there are internal quality factors, I think the most important ones have been mentioned already: Cohesion, Coupling, Encapsulation, Abstraction, ...
These can also augment the external quality factors:
High encapsulation, low coupling and high cohesion can help in maximizing reusability.
Now, if we are to narrow ourselves to what is "good code"; I'd have to say: Well encapsulated abstractions that exhibit low coupling and high cohesion. But I think "good code" is not enough to warrant a high quality software system.Per
Everything works on a PowerPoint slide
Bookmarks