Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #138589 > unrolled thread

Methodologies for C programming

Back to article view | Back to comp.lang.c

Contents

  Methodologies for C programming Thiago Adams <thiago.adams@gmail.com> - 2018-12-07 05:15 -0800
    Re: Methodologies for C programming Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-12-07 05:38 -0800
      Re: Methodologies for C programming Thiago Adams <thiago.adams@gmail.com> - 2018-12-07 07:57 -0800
        Re: Methodologies for C programming David Brown <david.brown@hesbynett.no> - 2018-12-07 18:05 +0100
    Re: Methodologies for C programming Thiago Adams <thiago.adams@gmail.com> - 2018-12-07 08:08 -0800
    Re: Methodologies for C programming William Ahern <william@25thandClement.com> - 2018-12-07 10:08 -0800
      Re: Methodologies for C programming Thiago Adams <thiago.adams@gmail.com> - 2018-12-07 10:23 -0800
    Re: Methodologies for C programming Wouter Verhelst <w@uter.be> - 2018-12-07 22:04 +0100
    Re: Methodologies for C programming Ian Collins <ian-news@hotmail.com> - 2018-12-08 10:46 +1300
      Re: Methodologies for C programming Thiago Adams <thiago.adams@gmail.com> - 2018-12-08 02:27 -0800
        Re: Methodologies for C programming Thiago Adams <thiago.adams@gmail.com> - 2018-12-08 10:35 -0800
          Re: Methodologies for C programming Jorgen Grahn <grahn+nntp@snipabacken.se> - 2018-12-09 08:22 +0000
    Re: Methodologies for C programming fir <profesor.fir@gmail.com> - 2018-12-09 14:40 -0800
    Re: Methodologies for C programming "Pascal J. Bourguignon" <pjb@informatimago.com> - 2018-12-27 13:17 +0100
      Re: Methodologies for C programming "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-12-27 08:12 -0500
      Re: Methodologies for C programming Thiago Adams <thiago.adams@gmail.com> - 2018-12-27 07:54 -0800
        Re: Methodologies for C programming Richard Damon <Richard@Damon-Family.org> - 2018-12-27 11:32 -0500
        Re: Methodologies for C programming fir <profesor.fir@gmail.com> - 2018-12-27 09:22 -0800
    Re: Methodologies for C programming jacobnavia <jacob@jacob.remcomp.fr> - 2018-12-27 19:54 +0100
      Re: Methodologies for C programming Richard Damon <Richard@Damon-Family.org> - 2018-12-27 17:54 -0500
        Re: Methodologies for C programming fir <profesor.fir@gmail.com> - 2018-12-27 16:24 -0800
          Re: Methodologies for C programming Chad <cdalten@gmail.com> - 2018-12-27 17:57 -0800
          Re: Methodologies for C programming Chad <cdalten@gmail.com> - 2018-12-27 17:58 -0800
            Re: Methodologies for C programming rbowman <bowman@montana.com> - 2018-12-27 21:34 -0700
              Re: Methodologies for C programming Keith Thompson <kst-u@mib.org> - 2018-12-27 21:27 -0800
                Re: Methodologies for C programming rbowman <bowman@montana.com> - 2018-12-28 08:30 -0700
                  Re: Methodologies for C programming Keith Thompson <kst-u@mib.org> - 2018-12-28 12:15 -0800
                    Re: Methodologies for C programming rbowman <bowman@montana.com> - 2018-12-28 20:42 -0700
                      Re: Methodologies for C programming Tim Rentsch <txr@alumni.caltech.edu> - 2018-12-29 09:26 -0800
                        Re: Methodologies for C programming rbowman <bowman@montana.com> - 2018-12-29 13:50 -0700
    Re: Methodologies for C programming luser droog <luser.droog@gmail.com> - 2018-12-30 12:39 -0800
      Re: Methodologies for C programming fir <profesor.fir@gmail.com> - 2018-12-30 14:00 -0800
        Re: Methodologies for C programming fir <profesor.fir@gmail.com> - 2018-12-30 14:18 -0800
      Re: Methodologies for C programming rbowman <bowman@montana.com> - 2018-12-30 16:48 -0700
        Re: Methodologies for C programming luser droog <luser.droog@gmail.com> - 2018-12-31 00:06 -0800
          Re: Methodologies for C programming fir <profesor.fir@gmail.com> - 2018-12-31 02:34 -0800
          Re: Methodologies for C programming Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-12-31 05:13 -0800
          Re: Methodologies for C programming rbowman <bowman@montana.com> - 2018-12-31 12:44 -0700
        Re: Methodologies for C programming Tim Rentsch <txr@alumni.caltech.edu> - 2019-01-01 16:01 -0800
        Re: Methodologies for C programming Tim Rentsch <txr@alumni.caltech.edu> - 2019-01-01 16:23 -0800
      Re: Methodologies for C programming Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-12-31 05:08 -0800
        Re: Methodologies for C programming Ike Naar <ike@iceland.freeshell.org> - 2018-12-31 17:32 +0000
          Re: Methodologies for C programming Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-12-31 14:13 -0800
    Re: Methodologies for C programming Thiago Adams <thiago.adams@gmail.com> - 2019-01-02 02:48 -0800

Page 1 of 3  [1] 2 3  Next page →

#138589 — Methodologies for C programming

Recently I became more interested in unity tests 
and modularization.  I can say that the C language is partially 
responsible for that.

When we think in unit test, we also think in TDD, although 
I think TDD does not exactly reflects the methodology I want 
to use.

The reason why C is the root of the interest is that when we 
start using C we need to build a lot infrastructure to program.

In C we need to build your own data types. Comparing with C++ 
for instance, we have parametrized data types like vector and map 
and other read-to-use types like string.

Therefore, to avoid doing everything again and again we need to 
think in modularization and reuse. Using C++ someone else is in 
charge for testing the STL containers. Doing you own data types 
we need to make sure everything is working and unit tests also 
become very important.

With methodologies do you use? 
What do you think about TDD? 
How to you reuse code?

[toc] | [next] | [standalone]

#138590

On Friday, December 7, 2018 at 1:16:17 PM UTC, Thiago Adams wrote:
> Recently I became more interested in unity tests 
> and modularization.  I can say that the C language is partially 
> responsible for that.
> 
> When we think in unit test, we also think in TDD, although 
> I think TDD does not exactly reflects the methodology I want 
> to use.
> 
> The reason why C is the root of the interest is that when we 
> start using C we need to build a lot infrastructure to program.
> 
> In C we need to build your own data types. Comparing with C++ 
> for instance, we have parametrized data types like vector and map 
> and other read-to-use types like string.
> 
> Therefore, to avoid doing everything again and again we need to 
> think in modularization and reuse. Using C++ someone else is in 
> charge for testing the STL containers. Doing you own data types 
> we need to make sure everything is working and unit tests also 
> become very important.
> 
> With methodologies do you use? 
> What do you think about TDD? 
> How to you reuse code?
>
I try to make a distinction between "this program only" and "many programs"
code. "Any program" doesn't mean "portable", it can be code to open
a file dialog in Windows. That's clearly "many programs" and a
large number of program need to open file dialogs whilst not needing the
full richness of the Microsoft native interface. Of course the dividing
line depends to some extent on how you work - if you are always writing
payroll programs then struct "employee" is many programs, if you expect to
write only one, it's a "this program only construct".

"Many programs" files also tend to be unit testable. They do things like
parse file formats, or apply transforms to images. "This program only" 
file are usually harder to unit test. You've either got to do a lot of
mocking or you have to test them with their surrounding callers and
dependencies, which is no longer unit testing. It's also more difficult
often to set up the input or test the output. Often it's what I call
"glue code", code which primarily calls other code with specific
data and displays the results.

 

[toc] | [prev] | [next] | [standalone]

#138592

On Friday, December 7, 2018 at 11:39:14 AM UTC-2, Malcolm McLean wrote:
> On Friday, December 7, 2018 at 1:16:17 PM UTC, Thiago Adams wrote:
> > Recently I became more interested in unity tests 
> > and modularization.  I can say that the C language is partially 
> > responsible for that.
> > 
> > When we think in unit test, we also think in TDD, although 
> > I think TDD does not exactly reflects the methodology I want 
> > to use.
> > 
> > The reason why C is the root of the interest is that when we 
> > start using C we need to build a lot infrastructure to program.
> > 
> > In C we need to build your own data types. Comparing with C++ 
> > for instance, we have parametrized data types like vector and map 
> > and other read-to-use types like string.
> > 
> > Therefore, to avoid doing everything again and again we need to 
> > think in modularization and reuse. Using C++ someone else is in 
> > charge for testing the STL containers. Doing you own data types 
> > we need to make sure everything is working and unit tests also 
> > become very important.
> > 
> > With methodologies do you use? 
> > What do you think about TDD? 
> > How to you reuse code?
> >
> I try to make a distinction between "this program only" and "many programs"

Something I need in almost all projects is a string builder
data type.
I am copy-pasting the code and generating an slightly 
different version in each project.

[toc] | [prev] | [next] | [standalone]

#138598

On 07/12/18 16:57, Thiago Adams wrote:
> On Friday, December 7, 2018 at 11:39:14 AM UTC-2, Malcolm McLean wrote:
>> On Friday, December 7, 2018 at 1:16:17 PM UTC, Thiago Adams wrote:
>>> Recently I became more interested in unity tests 
>>> and modularization.  I can say that the C language is partially 
>>> responsible for that.
>>>
>>> When we think in unit test, we also think in TDD, although 
>>> I think TDD does not exactly reflects the methodology I want 
>>> to use.
>>>
>>> The reason why C is the root of the interest is that when we 
>>> start using C we need to build a lot infrastructure to program.
>>>
>>> In C we need to build your own data types. Comparing with C++ 
>>> for instance, we have parametrized data types like vector and map 
>>> and other read-to-use types like string.
>>>
>>> Therefore, to avoid doing everything again and again we need to 
>>> think in modularization and reuse. Using C++ someone else is in 
>>> charge for testing the STL containers. Doing you own data types 
>>> we need to make sure everything is working and unit tests also 
>>> become very important.
>>>
>>> With methodologies do you use? 
>>> What do you think about TDD? 
>>> How to you reuse code?
>>>
>> I try to make a distinction between "this program only" and "many programs"
> 
> Something I need in almost all projects is a string builder
> data type.
> I am copy-pasting the code and generating an slightly 
> different version in each project.
> 

Frankly, if you need a lot of string use or string functions for a
particular piece of code, C is probably not the best language to use in
the first place.  C is a great language in its place - but it is not the
best choice for all programming tasks.

[toc] | [prev] | [next] | [standalone]

#138593

On Friday, December 7, 2018 at 11:16:17 AM UTC-2, Thiago Adams wrote:
...
> When we think in unit test, we also think in TDD, although 
> I think TDD does not exactly reflects the methodology I want 
> to use.

The methodology I am trying to do, is to create a stack
of reusable modules and create unit tests for each layer.
Because the modules are not solid, in a sense that I can 
change and improve, I need a way to refactory and re-check
everything.

The bad point is that if I have a shared file then changing
this file at one project can break the other.
In the other hand, if the other project uses a copy of the
file instead of sharing it, I will possibly create different
versions of the same module (that is happening now)


It seams that I need a folder with all files from all 
projects together.
Each project or module is a selection of one or more
files. Trying to separate the files with folders don't help
because the selection and combinations can change in each 
project.

[toc] | [prev] | [next] | [standalone]

#138600

Thiago Adams <thiago.adams@gmail.com> wrote:
> 
> 
> Recently I became more interested in unity tests 
> and modularization.  I can say that the C language is partially 
> responsible for that.
> 
> When we think in unit test, we also think in TDD, although 
> I think TDD does not exactly reflects the methodology I want 
> to use.
> 
> The reason why C is the root of the interest is that when we 
> start using C we need to build a lot infrastructure to program.
> 
> In C we need to build your own data types. Comparing with C++ 
> for instance, we have parametrized data types like vector and map 
> and other read-to-use types like string.
> 
> Therefore, to avoid doing everything again and again we need to 
> think in modularization and reuse. Using C++ someone else is in 
> charge for testing the STL containers. Doing you own data types 
> we need to make sure everything is working and unit tests also 
> become very important.
> 
> With methodologies do you use? 
> What do you think about TDD? 
> How to you reuse code?
> 

The secret to C development (and one reason C is still so popular) is having
a well-defined problem to which you can narrowly tailor your data
structures. Pre-cooked, polymorphic list or tree data structure are nice,
but their marginal utility is slight in the larger scheme of things.

It's the relationship between your objects, their lifetimes, and the flow of
execution--basically a vision of a lean, cohesive, minimal program or
library--that should be the focus. The program or library *is* the data
structure your building.

Imagine writing a custom string data structure, like maybe a specialized
rope construct. The languages existing string object (or objects) are of
little utility. Being able to implement a custom string data structure that
is polymorphic over some type is sort of useless because by definition the
shape and semantics are peculiar to your particular use case. In the same
way, when you write a program or library it's specialized (or should be) in
a way that the availability of generics, internally or externally, is of
lesser value than elsewhere. It might be aesthetically pleasing to be able
to export a generic Iterator or "stringy-thing" interface, but it's unlikely
that the consumers of your data structure are working in a context where the
surrounding code is or will ever be agnostic about the type or usage
semantics, so what does it matter (or rather, how much does it actually
matter) that they have to use your dedicated types and interfaces?

For basic data structures the traditional BSD list implementations
(<sys/queue.h>) and the slightly newer tree implementations (<sys/tree.h>)
have been more than sufficient for me. They're type safe and proven.
Performance has never been an issue because performance is invariably a
problem-specific matter. The cache-unfriendliness of a red-black tree
doesn't much matter if you're already memory throttled, and in any event the
<sys/tree.h> implementations have half the pointer chasing of typical
libraries. The obsession with bikeshedding hash table algorithms and
microperformance in languages like Rust or Python, for example, has more to
do with language constraints as well as the problem domains developers using
those languages typically work in. Admonishments to always reuse existing
libraries (e.g. STL in C++) is not particularly appropriate to a language
like C. Once you move beyond the need for basic lists, your already
approaching virgin territory.

If the above points don't seem correct in context, I'd argue that's simply
strong evidence that C is the wrong language in that context.

So, code reuse? If your projects are solving well-defined problems and are
narrorly tailored, reuse is a matter of reusing that entire project (program
or library, even if just a single .c file) elsewhere. Resuse of *internal*
code is more a matter of preference and experience. IME people often mistake
*tailored* reuse for unnecessary duplication. Copying a function or family
of functions and than tweaking their implementation to better suite the
immediate problem is *okay*. Trying to make all the tools in your toolbox
generic is a good way to waste time and energy.

TDD? You should have a well-defined problem from the outset. Well-defined
problems often lend themselves to stable interfaces and semantics, though it
may take some serious consideration and initial experimentation before
writing any serious code. Stable interfaces make testing easier, and testing
is a great way to ensure your interfaces are appropriate and will remain
stable. Not sure what else there is to say. As with generic data structures
I've rarely found pre-baked testing frameworks particularly helpful. Worse,
one often spends more time struggling with conflicting dependencies and
assumptions--not just in code but in semantics, execution flow, OS
primitives, etc. The more narrowly tailored the problem and the more
narrowly tailored the solution then the less likely it is that framework
conveniences will be suited to or easily applied to your project. But
experiences and opinions vary widely and, not coincidenally, likely
correlate with problem domain.

When I can I prefer to leverage scripting languages--Perl XS once upon a
time, now Lua, for testing. Once you can invoke and tickle your code from a
scripting environment it becomes very simple not only to write tests, but to
iterate development. That also makes available more testing framework
alternatives, but the value-add is slight compared to getting to the point
where you can leverage scriptability.

[toc] | [prev] | [next] | [standalone]

#138601

On Friday, December 7, 2018 at 4:09:11 PM UTC-2, William Ahern wrote:
> Thiago Adams  wrote:
> > 
> > 
> > Recently I became more interested in unity tests 
> > and modularization.  I can say that the C language is partially 
> > responsible for that.
> > 
> > When we think in unit test, we also think in TDD, although 
> > I think TDD does not exactly reflects the methodology I want 
> > to use.
> > 
> > The reason why C is the root of the interest is that when we 
> > start using C we need to build a lot infrastructure to program.
> > 
> > In C we need to build your own data types. Comparing with C++ 
> > for instance, we have parametrized data types like vector and map 
> > and other read-to-use types like string.
> > 
> > Therefore, to avoid doing everything again and again we need to 
> > think in modularization and reuse. Using C++ someone else is in 
> > charge for testing the STL containers. Doing you own data types 
> > we need to make sure everything is working and unit tests also 
> > become very important.
> > 
> > With methodologies do you use? 
> > What do you think about TDD? 
> > How to you reuse code?
> > 
> 
> The secret to C development (and one reason C is still so popular) is having
> a well-defined problem to which you can narrowly tailor your data
> structures. Pre-cooked, polymorphic list or tree data structure are nice,
> but their marginal utility is slight in the larger scheme of things.
> 
> It's the relationship between your objects, their lifetimes, and the flow of
> execution--basically a vision of a lean, cohesive, minimal program or
> library--that should be the focus. The program or library *is* the data
> structure your building.


I agree with you here. In C we have this very condensed
solution.

But I also have cases where the same code can be shared.
For instance, sometimes I need parser xml or json or html
or C etc..What all have in common is input stream that can 
be used with files or strings and can report the current line 
and col. thread pool is also something can be used in any 
program. utf8 etc.

[toc] | [prev] | [next] | [standalone]

#138605

On 7/12/2018 14:15, Thiago Adams wrote:
> Recently I became more interested in unity tests 
> and modularization.  I can say that the C language is partially 
> responsible for that.
> 
> When we think in unit test, we also think in TDD, although 
> I think TDD does not exactly reflects the methodology I want 
> to use.
> 
> The reason why C is the root of the interest is that when we 
> start using C we need to build a lot infrastructure to program.
> 
> In C we need to build your own data types. Comparing with C++ 
> for instance, we have parametrized data types like vector and map 
> and other read-to-use types like string.

It's true that C doesn't have things like the STL in C++. However, that
doesn't mean you need to build it yourself; there are plenty of
libraries available that you can use.

Me, I'm a big fan of the GLib utility library that is at the base of the
GTK+ stack. It contains things like hash tables and dynamic arrays
(partially implemented with macros), a thread pool, boxed types, and a
number of string utility tools.

In cases where using GLib was not an option, I've occasionally fallen
back to using C++ STL types behind an 'extern "C"' interface that used
void* for holding the data.

> Therefore, to avoid doing everything again and again we need to 
> think in modularization and reuse. Using C++ someone else is in 
> charge for testing the STL containers. Doing you own data types 
> we need to make sure everything is working and unit tests also 
> become very important.
> 
> With methodologies do you use? 
> What do you think about TDD? 

In cases where the tool you try to write is a noninteractive tool that
will be data-driven, then doing test-driven development can be a good
way to design what you want to do; you write a few test cases (i.e., a
few example files that explore all the edge cases), and then start
working on a tool that manages to successfully process all the test cases.

In most other cases, however, TDD is not necessarily a good idea.

> How to you reuse code?

That's what libraries are for :-)

[toc] | [prev] | [next] | [standalone]

#138608

On 08/12/2018 02:15, Thiago Adams wrote:
> 
> 
> Recently I became more interested in unity tests
> and modularization.  I can say that the C language is partially
> responsible for that.
> 
> When we think in unit test, we also think in TDD, although
> I think TDD does not exactly reflects the methodology I want
> to use.
> 
> The reason why C is the root of the interest is that when we
> start using C we need to build a lot infrastructure to program.
> 
> In C we need to build your own data types. Comparing with C++
> for instance, we have parametrized data types like vector and map
> and other read-to-use types like string.
> 
> Therefore, to avoid doing everything again and again we need to
> think in modularization and reuse. Using C++ someone else is in
> charge for testing the STL containers. Doing you own data types
> we need to make sure everything is working and unit tests also
> become very important.

If you are rolling your own.  There are often high quality opensource 
libraries available from exiting projects.

> With methodologies do you use?

Mostly TDD and as many XP practices as we can squeeze int.

> What do you think about TDD?

Use it just about everywhere.  On my current project my fellow 
architects are also keen TDDers so it is widely used for all of the 
languages we use.  For C specifically, the path of least resistance for 
unit testing is a C++ framework such as Googletest.

> How to you reuse code?

Usually by extracting useful nuggets into libraries.  TDD tends to 
produce lots of small functions (or objects in an OO language) which is 
a good start for building reusable components.

-- 
Ian.

[toc] | [prev] | [next] | [standalone]

#138615

On Friday, December 7, 2018 at 7:46:58 PM UTC-2, Ian Collins wrote:
[...]
> If you are rolling your own.  There are often high quality opensource 
> libraries available from exiting projects.

When I wrote this topic I was creating (again) one
input stream that has line an column and that can
be used with files or strings. 

I didn't search for it  because I think it is very 
specific. I think libraries are published as complete 
solutions, like to search for XML parser or JSON parser 
lib.  If you need both in your code, and you use libs, 
them probably, each one has its own input stream with line 
and col. (Adding many libraries can create a bigger program)


This problem (input stream with line and col) is not C specific. 
Probably I would need to create this for C++ as well.

Something I miss in the C standard is a string input stream
and string output stream.

The string builder data type for instance, that is one that
all need all the time, is used inside the tokenizer, let's 
say JSON tokenizer. It is required because the size of what 
we read is variable. Can be a small string or big one. 
The same happen in XML parser or in any parser that
can read values of variable size. 


One difference using C++ is that I would be lazy and
use std::string as string builder even if it is not the 
best option. Sometimes, for tools, this is not a problem, 
the same for using c++ string streams that are very slow.

In C I have two types of string builders. One is to 
be used as temporary and starts with some memory allocated
on stack. And the other one used heap always because 
generally the memory is moved. In C++, we also  used
std::string to just hold strings, not to build strings.
Then generally, more memory is wasted, compared with 
the solution I use in C. (I have a data type that is just
typedef char* to hold the string.)

The other property I am trying to archive using some 
methodology is consistency.

Do you know a nice C coding standard to follow?

Sharing code between projects is also a way to archive
consistency. 

I think this is also very relevant in the C language
because in C we can do the same think in many ways.
Some languages with big frameworks like Java or C# archive 
this consistence because we just copy the way of the 
framework is.
In C the standard is very minimalist and I personally don't
see it as something to follow in style while creating programs.

[toc] | [prev] | [next] | [standalone]

#138620

Other aspect of methodology I would like to ask 
is about documentation.

Do you document your code/algorithm/data structures at 
the source code?

When I have some external specification, like 
protocols or standard or other documentation not produced
by my I just link (//see at.. )the code against the 
documentation. Generally I make a copy and keep the inside 
the source control, then I know what is the version I am 
following.

For my own code, I am not sure if I document inside the code or
inside the test cases (like run-time concepts checked with
assertions) or if I need to create some pdf with description.
When the explanation requires diagrams or drawings then I think
a pdf is a good option.

How do you do? 
Here I am talking about profession production code.

[toc] | [prev] | [next] | [standalone]

#138626

On Sat, 2018-12-08, Thiago Adams wrote:
> Other aspect of methodology I would like to ask 
> is about documentation.
>
> Do you document your code/algorithm/data structures at 
> the source code?

Yes.  And there's a lot you can say about /how/ to do that,
but it's kind of offtopic and has been discussed at length before.

> When I have some external specification, like 
> protocols or standard or other documentation not produced
> by my I just link (//see at.. )the code against the 
> documentation. Generally I make a copy and keep the inside 
> the source control, then I know what is the version I am 
> following.

Make sure your license is compatible with the license of the
specification you're using.  At least if you plan to distribute
your code.

> For my own code, I am not sure if I document inside the code or
> inside the test cases (like run-time concepts checked with
> assertions) or if I need to create some pdf with description.

I don't believe in unit tests as documentation.  I mostly document
types and functions.

Writing end-user documentation (in my case, man pages) is also very
helpful.  When I write a new program or modify an existing one, I
write the man page first.

> When the explanation requires diagrams or drawings then I think
> a pdf is a good option.

I try to avoid non-text documentation at all cost, because it doesn't
work with version control.  Documentation which isn't kept together
with the code always fails IME.

ASCII art is almost always good enough for diagrams.  Other options
include graphviz.

> How do you do? 
> Here I am talking about profession production code.

I'm talking about hobby code.  When I write code at work, I do as I'm
told, unless there are no rules and no established conventions.

/Jorgen

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .     .
\X/     snipabacken.se>   O  o   .

[toc] | [prev] | [next] | [standalone]

#138632

W dniu piątek, 7 grudnia 2018 14:16:17 UTC+1 użytkownik Thiago Adams napisał:
> Recently I became more interested in unity tests 
> and modularization.  I can say that the C language is partially 
> responsible for that.
> 
> When we think in unit test, we also think in TDD, although 
> I think TDD does not exactly reflects the methodology I want 
> to use.
> 
> The reason why C is the root of the interest is that when we 
> start using C we need to build a lot infrastructure to program.
> 
> In C we need to build your own data types. Comparing with C++ 
> for instance, we have parametrized data types like vector and map 
> and other read-to-use types like string.
> 
> Therefore, to avoid doing everything again and again we need to 
> think in modularization and reuse. Using C++ someone else is in 
> charge for testing the STL containers. Doing you own data types 
> we need to make sure everything is working and unit tests also 
> become very important.
> 
> With methodologies do you use? 
> What do you think about TDD? 
> How to you reuse code?

1. those are general questions and was discussed over a years - repeating it (as i know it) is not much fun to me

2. tbh the answers you can get here are 
like "toy answers" just write normal c code and what else, what up

as i get more experienced it showed to me
that those project strusture and conventions etc are not most important (banal) the more importance is not in the conventions but in you (or in me in that respect) the bigger problem (or art) is to make myself to code 

...some call this aspect as motivation or 'setting' but i would be closed to name it as a 'drive' - and the problem is how to find a good drive to code good things.. this is the real problem

afaik nmany good programmers abandon coding when they become good and i must say i understand it somewhat (at some level it is hard to still stay there)

tell me how to do THAT as this is real problem, not the banal questions with banal answers you state ;c

[toc] | [prev] | [next] | [standalone]

#139117

Thiago Adams <thiago.adams@gmail.com> writes:
> With methodologies do you use? 
> What do you think about TDD? 
> How to you reuse code?

Methodologies don't depend on the programming language, but on the size
and kind of project.

Given a project kind and size, and other factors, you will choose a team
size (or several teams!), and you will decide on a methodology
accordingly.

The programming language choice is made in function of other technical
requirements (including the target platform, and the team experience).

--
__Pascal__

[toc] | [prev] | [next] | [standalone]

#139118

On 12/27/2018 7:17 AM, Pascal J. Bourguignon wrote:
> Thiago Adams <thiago.adams@gmail.com> writes:
>> With methodologies do you use?
>> What do you think about TDD?
>> How to you reuse code?
> 
> Methodologies don't depend on the programming language, but on the size
> and kind of project.
> 
> Given a project kind and size, and other factors, you will choose a team
> size (or several teams!), and you will decide on a methodology
> accordingly.

You will also choose a methodology based on the programming language.
My design for a system using an OO language would be notably different
than a procedural one.

> The programming language choice is made in function of other technical
> requirements (including the target platform, and the team experience).

There are other reasons to choose a particular language over another.
Royalty-free runtime distribution, the licensing model, does each target
customer have to purchase something to use it, or is it self-contained.

Many factors, including the target machine's resources.  If you're in a
situation where you're limited to 1 core and 32MB of RAM for an embedded
CPU, it will use a completely different toolset than a modern machine
with 64GB of memory and 16+ cores.

Many factors.

-- 
Rick C. Hodgin

[toc] | [prev] | [next] | [standalone]

#139128

On Thursday, December 27, 2018 at 10:17:15 AM UTC-2, Pascal J. Bourguignon wrote:
> Thiago Adams  writes:
> > With methodologies do you use? 
> > What do you think about TDD? 
> > How to you reuse code?
> 
> Methodologies don't depend on the programming language, but on the size
> and kind of project.

Points where C is different from other languages:

 1 - We need to create a lot of basic code, data structures
     compared with other languages like C++, Java, C#...

     So, for instance, we need to choose a methodology to test
     this basic code. We need to build the program and see if
     the ideas are working. Before to make the perfect
     data structure we need to move forward implement other parts.
     Then latter it is time to put more attention on the basic
     code we had created some months ago and trying to move forward
     incrementally. This can happen in any language but in C this 
     is very common. strings, dynamic arrays, error codes..


 2 - There is no common (universal) pattern for libraries or for code 
     organization build etc etc.
     Some languages like C# that has a big framework you can just
     copy the way the framework is implemented. Languages with modules
     also creates a common pattern for usage and distribution.

 3  - In C everything is very customized. If you have to create something
      then you create just what you use and for the specif cases.
      This is an advantage in terms of size and performance, but at the
      same time customized code can be difficult to reuse.
      Personally I reuse code but I change it a little each time I reuse.

 

[toc] | [prev] | [next] | [standalone]

#139131

On 12/27/18 10:54 AM, Thiago Adams wrote:
> On Thursday, December 27, 2018 at 10:17:15 AM UTC-2, Pascal J. Bourguignon wrote:
>> Thiago Adams  writes:
>>> With methodologies do you use? 
>>> What do you think about TDD? 
>>> How to you reuse code?
>>
>> Methodologies don't depend on the programming language, but on the size
>> and kind of project.
> 
> Points where C is different from other languages:
> 
>  1 - We need to create a lot of basic code, data structures
>      compared with other languages like C++, Java, C#...
> 
>      So, for instance, we need to choose a methodology to test
>      this basic code. We need to build the program and see if
>      the ideas are working. Before to make the perfect
>      data structure we need to move forward implement other parts.
>      Then latter it is time to put more attention on the basic
>      code we had created some months ago and trying to move forward
>      incrementally. This can happen in any language but in C this 
>      is very common. strings, dynamic arrays, error codes..
> 
> 
>  2 - There is no common (universal) pattern for libraries or for code 
>      organization build etc etc.
>      Some languages like C# that has a big framework you can just
>      copy the way the framework is implemented. Languages with modules
>      also creates a common pattern for usage and distribution.
> 
>  3  - In C everything is very customized. If you have to create something
>       then you create just what you use and for the specif cases.
>       This is an advantage in terms of size and performance, but at the
>       same time customized code can be difficult to reuse.
>       Personally I reuse code but I change it a little each time I reuse.

Another way to view this is that many other ('higher level') languages
are designed to support certain specific methodologies, and make it easy
and even natural to use them. C does not, as it is lower level and broad
in the methodologies it 'supports'.

Many other languages, because they focus on particular methodologies,
often include as part of the standard language, frameworks to support
that methodology, and that helps focus how that methodology is used in
that language. C, because it doesn't focus on any particular
methodology, doesn't include such frameworks as part of its standard
library, but in many cases there are a large number of 3rd party
resource (of varying quality) to provide support for them.

One fundamental limitation of a generic framework is that to BE generic,
it will unlikely be tuned to your exact requirements when used 'as is'.
Often, the choice to use C is based on a desire to be efficient (if
execution efficiency isn't one of the top goals, frequently a higher
level language can be much more efficient in getting the program
written), so there is more of a tendency to use 'cut and paste' reuse
where pull in the code and adjust it to the particular application. THIS
IS STILL A FORM OF REUSE. Perhaps sometimes you can pull in the package
and not need to edit it, or maybe not yet, you wait till that becomes
the performance bottleneck, and sometimes you find that you can create a
common code piece that is mostly reusable for your type of applications
that is normally 'good enough'.

[toc] | [prev] | [next] | [standalone]

#139134

W dniu czwartek, 27 grudnia 2018 16:54:51 UTC+1 użytkownik Thiago Adams napisał:
> On Thursday, December 27, 2018 at 10:17:15 AM UTC-2, Pascal J. Bourguignon wrote:
> > Thiago Adams  writes:
> > > With methodologies do you use? 
> > > What do you think about TDD? 
> > > How to you reuse code?
> > 
> > Methodologies don't depend on the programming language, but on the size
> > and kind of project.
> 
> Points where C is different from other languages:
> 
>  1 - We need to create a lot of basic code, data structures
>      compared with other languages like C++, Java, C#...
> 
>      So, for instance, we need to choose a methodology to test
>      this basic code. We need to build the program and see if
>      the ideas are working. Before to make the perfect
>      data structure we need to move forward implement other parts.
>      Then latter it is time to put more attention on the basic
>      code we had created some months ago and trying to move forward
>      incrementally. This can happen in any language but in C this 
>      is very common. strings, dynamic arrays, error codes..
> 
> 
>  2 - There is no common (universal) pattern for libraries or for code 
>      organization build etc etc.
>      Some languages like C# that has a big framework you can just
>      copy the way the framework is implemented. Languages with modules
>      also creates a common pattern for usage and distribution.
> 
>  3  - In C everything is very customized. If you have to create something
>       then you create just what you use and for the specif cases.
>       This is an advantage in terms of size and performance, but at the
>       same time customized code can be difficult to reuse.
>       Personally I reuse code but I change it a little each time I reuse.


what damn methodology ? ??
i personally know only one c methodology:
write it normal way

in c sources there are more differences but i think its more difference by style 
not 'methodology' (maybe tehere are some methodlogies but i never heard)

and as to style the most important point is probably: dont use macros (c without macros gets much more normal imo), also longer descriptive function names are important

[toc] | [prev] | [next] | [standalone]

#139136

Le 07/12/2018 à 14:15, Thiago Adams a écrit :
> In C we need to build your own data types. Comparing with C++
> for instance, we have parametrized data types like vector and map
> and other read-to-use types like string.
> 
> Therefore, to avoid doing everything again and again we need to
> think in modularization and reuse. Using C++ someone else is in
> charge for testing the STL containers. Doing you own data types
> we need to make sure everything is working and unit tests also
> become very important.

To avoid that, I designed and developed a prototype STL for C, offering 
very similar capabilities and faster performance.

The C standards committee rejected the proposal saying that C++ has done 
that already, and any development of an STL in C is out of the question.

I have tried to promote the library in this group (used mainly by C++ 
people)  to no avail.

What is the CCL?

It provides
o Hash tables
o Flxible vectors
o Trees
o String vectors
o lists (single/double linked)

Parametized types are provides through macros.
Allocation can be replace by your own allocator.

It provides also iterators, you can be notified of changes in anyy 
container, provides read only containers, and a LONG "etc"

But it has an enormous drawback:

It is written in standard C (1999), and as everyone in this group has 
told me, C is a dead language, goto C++

[toc] | [prev] | [next] | [standalone]

#139146

On 12/27/18 1:54 PM, jacobnavia wrote:
> Le 07/12/2018 à 14:15, Thiago Adams a écrit :
>> In C we need to build your own data types. Comparing with C++
>> for instance, we have parametrized data types like vector and map
>> and other read-to-use types like string.
>>
>> Therefore, to avoid doing everything again and again we need to
>> think in modularization and reuse. Using C++ someone else is in
>> charge for testing the STL containers. Doing you own data types
>> we need to make sure everything is working and unit tests also
>> become very important.
> 
> To avoid that, I designed and developed a prototype STL for C, offering
> very similar capabilities and faster performance.
> 
> The C standards committee rejected the proposal saying that C++ has done
> that already, and any development of an STL in C is out of the question.
> 
> I have tried to promote the library in this group (used mainly by C++
> people)  to no avail.
> 
> What is the CCL?
> 
> It provides
> o Hash tables
> o Flxible vectors
> o Trees
> o String vectors
> o lists (single/double linked)
> 
> Parametized types are provides through macros.
> Allocation can be replace by your own allocator.
> 
> It provides also iterators, you can be notified of changes in anyy
> container, provides read only containers, and a LONG "etc"
> 
> But it has an enormous drawback:
> 
> It is written in standard C (1999), and as everyone in this group has
> told me, C is a dead language, goto C++
> 

Jacob, I have looked at and tried to use your library, but it comes off
feeling like C++ code that has been ported to C, not as C code, which I
think is part of the issue that the Standards Committee saw. If
anything, I think you set your sites on implementing too much of the
STL, and ended up with something that just doesn't feel like C.

In an application that I would be tempted to use it, I would with just a
bit of push go all the way to implementing in C++.

[toc] | [prev] | [next] | [standalone]

Page 1 of 3  [1] 2 3  Next page →

Back to top | Article view | comp.lang.c

csiph-web