gnucap-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnucap-devel] testing


From: al davis
Subject: Re: [Gnucap-devel] testing
Date: Mon, 9 Feb 2015 13:47:05 -0500
User-agent: KMail/1.13.7 (Linux/3.2.0-4-amd64; KDE/4.8.4; x86_64; ; )

On Sat, Jan 31, 2015 at 01:00:20AM -0500, al davis wrote:
> The statistics generated is much more detailed, but that's not 
> the goal.  The goal is to guide the human to make better code, 
> and to keep track of how it is going.

On Saturday 31 January 2015, Felix Salfelder wrote:
> disagreed. if you use gcov to compute the percentage of
> visited branches, the result will be the percentage of
> visited branches. i have not considered that, as i use
> "untested()" myself... it's just that the "untested()" fuzz
> all over the code is mostly confusing to anybody else. it
> introduces unnecessary coding rules, and thus is a waste of
> time.

really?

Every project has its style.  Anyone coming in from outside 
needs to take some time to understand it, even if the intent is 
to change it.  Otherwise, over time it turns into a big mess.

It doesn't take much to explain the test macros.  I like the 
idea of executable comments, and that the weak spots are marked 
so anyone can see them.

Long ago, I used to use gconv for this kind of thing.  The test 
macros came out of frustration with how cumbersome the separate 
tools were.  Testing should not be an afterthought.  It's part 
of design.

I decided to try gconv again.  For a small project it is 
manageable, and produces lots of data.  I don't think it is more 
useful than what I get out of the test macros.  Also, I didn't 
get it to work with libraries, plugins, and generated code, but 
I didn't try very hard.

I think gnucap has a lot less fuzz than most other projects I 
have seen, and this is largely because of the test macros.

Coding rules?  Again, if it isn't consistent, it turns into a 
big mess.  It may seem foreign to always use curlys, and to have 
explicitly empty blocks.  That's to draw attention to "what 
happens here", which otherwise seems to be ignored, leading to 
uninitialized variables, dangling pointers, and the like.  When 
I have to debug other peoples code, I look first at the absent 
elses as a source of bugs, and often find them there.

I didn't always do it this way.  The way it is evolved over many 
years.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]