[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.
- Re: [Gnucap-devel] testing,
al davis <=
- Re: [Gnucap-devel] testing, al davis, 2015/02/09
- Re: [Gnucap-devel] testing, Felix Salfelder, 2015/02/09
- Re: [Gnucap-devel] testing, al davis, 2015/02/09
- [Gnucap-devel] Makefiles again, Felix Salfelder, 2015/02/09
- Re: [Gnucap-devel] Makefiles again, al davis, 2015/02/09
- Re: [Gnucap-devel] Makefiles again, Felix Salfelder, 2015/02/10
- Re: [Gnucap-devel] Makefiles again, Felix Salfelder, 2015/02/10
- Re: [Gnucap-devel] testing, Felix Salfelder, 2015/02/10
- Re: [Gnucap-devel] testing, al davis, 2015/02/13
- Re: [Gnucap-devel] testing, Felix Salfelder, 2015/02/13