The Artima Developer Community
Sponsored Link

Weblogs Forum
Where Did All the Beautiful Code Go?

97 replies on 7 pages. Most recent reply: Apr 14, 2006 9:55 PM by Andy Dent

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 97 replies on 7 pages [ « | 1 ... 2 3 4 5 6 7 | » ]
Vincent O'Sullivan

Posts: 724
Nickname: vincent
Registered: Nov, 2002

Re: Where Did All the Beautiful Code Go? Posted: Mar 30, 2006 2:48 PM
Reply to this message Reply
Advertisement
> > "There is one code quality tool
> > whose use used to be widespread but which pretty died
> > out
> > (in my experience) about ten years ago.
>
> You're doing it here at Artima right now.

Not really. What we're talking about here is pretty much the theory of programming. What I think we should be doing more of (again) in our daily work, is subjecting the actual code we write to more peer review. Many of the 'bad' practices that have been mentioned work because they are quick, they do the job and their payload of future problems are hidden from the sight of others. Knowledge that you must justify your code to you colleages before you commit it concentrates the mine wonderfully.

Jim Shi

Posts: 7
Nickname: jim2000
Registered: May, 2005

Re: Where Did All the Beautiful Code Go? Posted: Mar 30, 2006 4:07 PM
Reply to this message Reply
Yea I always wonder why MS can get away with its messy
API for such a long time.

Jeff Ratcliff

Posts: 242
Nickname: jr1
Registered: Feb, 2006

Re: Where Did All the Beautiful Code Go? Posted: Mar 30, 2006 5:05 PM
Reply to this message Reply
In theory peer review of code is great. The problem is that it's easier for the reviewer to focus on variable names, braces, commenting style etc., than it is on finding bugs.

Perhaps if there were a rule that you must find a real bug before you can comment on anything else, code reviews would actually result in higher quality code.

Kay Schluehr

Posts: 302
Nickname: schluehk
Registered: Jan, 2005

Re: Where Did All the Beautiful Code Go? Posted: Mar 30, 2006 10:01 PM
Reply to this message Reply
> Writing and maintaining tests are expensive, but how else
> are you going to consistently verify that your code is
> working correctly? I would argue that the most serious
> technical debt you can have is the lack of tests, and that
> the correct place to put a significant portion of your
> resources is into testing. Otherwise, how are you ensuring
> that your system is working correctly? Are you just saying
> "I tried it, and it worked for me, so you should trust me
> that it's working correctly"?

Strange enough but I find the matter of unit-testing and code-quality mostly unrelated. I've seen horrible but very well tested code. For a live example: I've always struggled to get into PyPys code base. It's much simpler to navigate through CPythons although it is written in C. Both are well tested but the one seems to be driven by random research ideas that generates it's legacy where it advances while the other shows an overall consistency: predictable data structures and wrapper code.

As mentioned by others code correctness cannot be proved by unit tests as already Dijkstra pointed out. It nevertheless increases reliability enourmously. I wonder whether this could not be proved using statistical analysis involving unit tests and code coverage metrics.

Vincent O'Sullivan

Posts: 724
Nickname: vincent
Registered: Nov, 2002

Re: Where Did All the Beautiful Code Go? Posted: Mar 31, 2006 2:08 AM
Reply to this message Reply
> In theory peer review of code is great. The problem is
> that it's easier for the reviewer to focus on variable
> names, braces, commenting style etc., than it is on
> finding bugs.

Yes, I agree and I think that the core problem of peer review was always finding two or three people who had the time, inclination and capability to look at your code and make useful comments. The reality was, as you say, that most reviews were themselves 'quick and dirty'. Did the code compile? Does it meet the company's basic coding standards? etc. Indeed, if the code includes all the relevant unit tests then there shouldn't be any bugs either. In fact, these are all preconditions that should hold before the peer review takes place

None of that addresses the 'beautiful code' problem though. It's quite possible for code to meet all the above criteria and still be 'ugly'.

Nevertheless, there are three potential benefits that should be the aim of peer review.
+ Firstly; Defensive Coding: if people know they have to stand up and defend their code in detail then they are more likely to write code that can be defended.
+ Secondly; Communication: There is nothing like looking at what they're writing to tell you what your colleages are actually doing. 'Show me the meat' is, I think, the American colloquialism.
+ Thirdly; Education: We all, more or less, know how to code but we can only code what we know. Knowledge of best practice, patterns, specialist tools, libraries, APIs, etc., etc. is much more thinly spread. Reviews are an ideal opportunity to communicate such knowledge, particularly when it can be applied to concrete examples of new code.

This theory is all very well but when, in practice, you can't find people who are prepared to put the time in to doing it properly then it remains just theory. (Much in the same way that it's largely impossible to find the right customers; the ones who have the time and knowledge to discuss what it is that you're trying to code for them in the first place.)

Communication seems to be the key missing ingredient.

Achilleas Margaritis

Posts: 674
Nickname: achilleas
Registered: Feb, 2005

Re: Where Did All the Beautiful Code Go? Posted: Mar 31, 2006 2:09 AM
Reply to this message Reply

Writing and maintaining tests are expensive, but how else are you going to consistently verify that your code is working correctly?


Programming languages should not allow code that does not implement the requirements with 100% correctness. That means requirements has to be part of the language, so as that the compiler checks the implementation against the requirements. Before someone says "halting problem", I would like to point out that most tasks are provable, and not all problems are about proving facts about numbers anyway.


That's not even the real problem. It's when we need to add new functionality that things get really ugly. Because each function of the system is basically monolithic, there's no way to quarantine the ugly parts. We have to get knee-deep into it start banging on it's fragile components. For example, adding a new field to the output requires dozens of code changes and many are non-trivial and could easily throw the code out-of-whack (for example: one process passes data in two arrays though half-a-dozen Objects and classes and there are dozens of dependencies against them. Modifying the order of one array with out modifying the other could cause massively incorrect output that might only be sporadic.


That is why the functional approach is better in programming than anything else: it makes dependencies like the one you describe as functions, so changing things becomes easier. The real problem is that sequence/order is often a type, but not many programming languages acknowledge that.

Kay Schluehr

Posts: 302
Nickname: schluehk
Registered: Jan, 2005

Re: Where Did All the Beautiful Code Go? Posted: Mar 31, 2006 6:01 AM
Reply to this message Reply
>
> Writing and maintaining tests are expensive, but how else
> are you going to consistently verify that your code is
> working correctly?
>

>
> Programming languages should not allow code that does not
> implement the requirements with 100% correctness.

I don't understand how a PL can check that a programmer implemented requirements correctly. I guess it would not even help when the compiler scans the programmers and customers brains?

Jeff Ratcliff

Posts: 242
Nickname: jr1
Registered: Feb, 2006

Re: Where Did All the Beautiful Code Go? Posted: Mar 31, 2006 8:14 AM
Reply to this message Reply
> Programming languages should not allow code that does not
> implement the requirements with 100% correctness. That
> means requirements has to be part of the language, so as
> that the compiler checks the implementation against the
> requirements.

I'm not sure what subset of problems (if any) could have their requirements built into the language but clearly real-time applications are not in that subset unless every relevent timing characteristic of the hardware it runs on was also incorporated into the language.

As far as I know, there is not an existing algorithm for scanning code to determine its real-time characteristics. Writing such a program would be so difficult and time-consuming that it would be hard to make the case that this would improve your ability to deliver a high-quality real-time application in a timely fashion.

Alex Stojan

Posts: 95
Nickname: alexstojan
Registered: Jun, 2005

Re: Where Did All the Beautiful Code Go? Posted: Mar 31, 2006 11:44 AM
Reply to this message Reply
> Programming languages should not allow code that does not
> implement the requirements with 100% correctness. That
> means requirements has to be part of the language, so as
> that the compiler checks the implementation against the
> requirements.

In what form would you specify the requirements so that the compiler can verify the code against it? Also, how would you make sure the requirements definition is correct?

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Where Did All the Beautiful Code Go? Posted: Mar 31, 2006 12:32 PM
Reply to this message Reply
> > Programming languages should not allow code that does
> not
> > implement the requirements with 100% correctness. That
> > means requirements has to be part of the language, so
> as
> > that the compiler checks the implementation against the
> > requirements.
>
> In what form would you specify the requirements so that
> the compiler can verify the code against it? Also, how
> would you make sure the requirements definition is correct?

You have to build a langauge for the requirements. Then you build a compiler for that language. Then to make sure your requirments are right, you define a language. Then a compiler for that. It's turtles all the way down.

Alex Stojan

Posts: 95
Nickname: alexstojan
Registered: Jun, 2005

Re: Where Did All the Beautiful Code Go? Posted: Mar 31, 2006 12:51 PM
Reply to this message Reply
> You have to build a langauge for the requirements. Then
> you build a compiler for that language. Then to make sure
> your requirments are right, you define a language. Then a
> compiler for that. It's turtles all the way down.

Exactly!!!

Vladimir Nesov

Posts: 27
Nickname: robotact
Registered: Aug, 2005

Re: Where Did All the Beautiful Code Go? Posted: Apr 1, 2006 11:01 AM
Reply to this message Reply
Problem with hacked code is also that it's more likely to introduce subtle inconsistencies.
Testing relies on assumption that tests represent more general case sets. When code is dirty, it takes much more tests to achieve the same reliability. So, it just emphasizes required methodology overhead when you can't keep project beautiful.

Jeff Ratcliff

Posts: 242
Nickname: jr1
Registered: Feb, 2006

Re: Where Did All the Beautiful Code Go? Posted: Apr 1, 2006 1:22 PM
Reply to this message Reply
> Testing relies on assumption that tests represent more
> general case sets. When code is dirty, it takes much more
> tests to achieve the same reliability. So, it just
> emphasizes required methodology overhead when you can't
> keep project beautiful.

Could you elaborate on this? I don't see how a unit test (assuming that's the kind of testing you're talking about) takes advantage of "general case sets".

Of course, one of the advantages of functional tests over unit tests is that the former is not dependent on the structure of the code and thus won't break if code is refactored.

Vladimir Nesov

Posts: 27
Nickname: robotact
Registered: Aug, 2005

Re: Where Did All the Beautiful Code Go? Posted: Apr 1, 2006 3:28 PM
Reply to this message Reply
Buggy software needs more testing. :)
Each test case is representative of set of test cases. When some test cases pass, we assume code operating correctly for extrapolated set of configurations. If code is consistent, its operation extrapolates more regularly.

Achilleas Margaritis

Posts: 674
Nickname: achilleas
Registered: Feb, 2005

Re: Where Did All the Beautiful Code Go? Posted: Apr 2, 2006 12:00 PM
Reply to this message Reply
I don't understand how a PL can check that a programmer implemented requirements correctly. I guess it would not even help when the compiler scans the programmers and customers brains?

A PL shall allow the programmer to declare the requirements, either as separate entities from the implementation, or as contracts. Much of the code in a program is requirements anyway. Then the compiler shall check that all of the requirements are implemented correctly.


I'm not sure what subset of problems (if any) could have their requirements built into the language


I was not talking about requirements built in the language, but the language to allow the programmer to express the requirements in a form that can be checked by the compiler.


clearly real-time applications are not in that subset unless every relevent timing characteristic of the hardware it runs on was also incorporated into the language.


The attributes of the hardware (like instruction timings, task switch delay etc) can exist as a separate library. By linking with a different library for each architecture, different hardware characteristics can be checked against the same program.


As far as I know, there is not an existing algorithm for scanning code to determine its real-time characteristics.


There is no need for an algorithm like that. For example, if a specific piece of code should run within a specific amount of time, then the compiler can easily count how many clock ticks a bunch of instructions takes to execute, and thus fail the code if the requirements are not met.


In what form would you specify the requirements so that the compiler can verify the code against it?


Requirements should be specified as descriptions of: a) static organization of data, b) action sequences, c) events, d) constraints on all these, e) other things I have forgotten.


Also, how would you make sure the requirements definition is correct?


You can not make sure the requirements are 100% correct, just like you can not make sure unit tests are 100% correct. But since requirements specify the 'what' of an application (the implementation specifies the 'how'), and requirements are declarative, it is much easier to see what is going on at the level of requirements rather than at implementation level. Furthermore, conflicting requirements will not compile.


You have to build a langauge for the requirements. Then you build a compiler for that language. Then to make sure your requirments are right, you define a language. Then a compiler for that. It's turtles all the way down.


Not really. All that is needed is to write such a compiler with traditional methods. Once there is an initial version, then the compiler can be written in itself.

Flat View: This topic has 97 replies on 7 pages [ « | 2  3  4  5  6  7 | » ]
Topic: Shuttleworth Foundation Workshop on Analytical Skills Development Previous Topic   Next Topic Topic: Software Architecture is Leadership

Sponsored Links



Google
  Web Artima.com   

Copyright © 1996-2019 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use