Writing Log messages into Memory

[NorthGuy]

the example was meant to demonstrate readability only. Not any other aspect of "good programming".

I see. So, you like the text of the program to be close to a natural language, such as Visual Basic, not concise and cryptic, such as Perl. I understand this point.

What are other aspects of "good programming"?

 

[misterT]

What are other aspects of "good programming"?

Lately, "separation of concerns" or "inversion of control" or "dependency injection" (all pretty much the same) has been very interesting to me. Especially how to apply it to embedded systems. That is really powerful way to write modular and testable code. Separating hardware independent code to the minimum etc. Atxmega is interesting uC because it is designed to work well with this kind of "design pattern".

Good programming process is that you first "make it work" and then "make it better".. and maybe then you have learned something about the problem in hand and write most of the code again from scratch.. every coder should have the courage and privilege to start from scratch if they come up with a better overall idea or design (if the project is not extremely large, then it is too late).

 

[NorthGuy]

Lately, "separation of concerns" or "inversion of control" or "dependency injection" (all pretty much the same) has been very interesting to me. Especially how to apply it to embedded systems. That is really powerful way to write modular and testable code. Separating hardware independent code to the minimum etc. Atxmega is interesting uC because it is designed to work well with this kind of "design pattern".

These are fancy words for object oriented programming OOP.

The problem is that all the current implementations use run-time binding, which makes them very inefficient in the embedded environment. For example, you wrote a program which does something with some device connected to some pins. Then you implement some sort of scheduler which calls into your routine. Everything is implemented as objects. These objects are connected together at run-time. But then nothing changes - the scheduler continues to schedule your routine and your routine continues to use the same device with the same pin. The built-in ability of your program to connect to other devices and other pins is not used at all. Same for the ability of the scheduler to run other tasks. Pins will not jump around and new tasks will not come to the MCU from nowhere.

All the binding can be done in compile-time, but the development tools, which are simply ported from big computers, do not work that way.

But anyway, these are design concepts. Some people use them, others don't. Would you say that only the people who use these concept have "good style" while others don't?

 

[misterT]

These are fancy words for object oriented programming OOP.

No.. You can write (and most do) very fancy OOP programs without using dependency injection (DI).. and eventually the code becomes spaghetti.
Same happens with many embedded applications. You can use DI with C easily and solve many problems..

It is fancy word for simple design pattern. But not so to easy apply.. Some OOP languages do not work well with DI (they do not allow omitting parameterless constructor. And writing the composition root is tricky for some frameworks).

Actually I would say that DI has nothing to do with OOP. Maybe it is even easier to implement in C than, say, C#.

Would you say that only the people who use these concept have "good style" while others don't?

No. It is very hard to say what is good style, or good programming. To me it is very creative process.. There are no strict rules.. keep your mind open and you will write the most beautiful code ever. Just don't stick to some old rules and copy-paste. Using patterns and your own experience is just a start. Then re-think and re-write.

If I read my old code I only see mistakes.

One thing is strict rule to me: Syntax style should be consistent at least in the same project.

 

[nsaspook]

An important part "good programming" to me is using the correct data structure for any program that stores and modifies more than trivial state information. One of the first things I like to do after 'making it work' is to look at the data relationships and flow to look for what's possibly fragile in crashes, needs better encapsulation, memory barriers or can just be eliminated/combined with something else related. It's one of the reasons C works well with embedded systems. C can create very efficient data structures that can be modified/copied directly as flat memory hunks instead of indirectly (by indirection nodes) as needed by some languages.

 

[NorthGuy]

No.. You can write (and most do) very fancy OOP programs without using dependency injection (DI).. and eventually the code becomes spaghetti.

IMHO, any data structure containing functions and data is an object. You do not need a special language to manipulate objects and call this OOP.

What you call DI is a very old thing. Think, for example, about files in any OS. You open a file, you're given a reference to the table of functions and data. You have no idea where the file is - it might be a com port, an Internet connection, a disk file, a pipe or whatever. You take it and work with it. Here's your DI.

Of course, people didn't know that they were doing DI for years. Most still don't.

If I read my old code I only see mistakes.

I recently had to rewrite a big program that I wrote around 1990-1995. I can tell you - I write better now. But I'm not as bold as I used to be

 

[misterT]

What you call DI is a very old thing. Think, for example, about files in any OS. You open a file, you're given a reference to the table of functions and data. You have no idea where the file is - it might be a com port, an Internet connection, a disk file, a pipe or whatever. You take it and work with it. Here's your DI.

True.. but I did not say it is a new thing. Recently there has been more books and "theory" around it. Because of that programmers are more aware of the "pattern" and can apply it more creatively. One thing is testability, and another thing is interception. Actually interception is the answer to the original problem of this thread..

Interception works like this: When you have some module that calls another module to do something:

client -----> service

Then you can just plug in another module in between without either of the original modules noticing anything:

client ---> logger ---> service

That is starting to sound like a good (or better) design.

 

[nsaspook]

Interception works like this: When you have some module that calls another module to do something:

client -----> service

Then you can just plug in another module in between without either of the original modules noticing anything:

client ---> logger ---> service

That is starting to sound like a good (or better) design.

The old saying is: Everything eventually becomes Unix

 

[nsaspook]

I recently had to rewrite a big program that I wrote around 1990-1995. I can tell you - I write better now. But I'm not as bold as I used to be

It depends on the language. I can look back at some Modula-2 code I wrote many years ago and still feel pretty good about it because that language forced you to write structured code.

A file from a crude OS addon I wrote for Atari ST.

 

[NorthGuy]

It depends on the language. I can look back at some Modula-2 code I wrote many years ago and still feel pretty good about it because that language forced you to write structured code.

Never seen Modula-2 bedore. Resembles Pascal. Doesn't look very obsolete. I guess someone might still use Modula-2 even today, although there could be a problem with compilers.

 

[nsaspook]

There are still good compiler front-ends for M2 today for gcc. **broken link removed**
Ada (a Pascal-like language) and Modula share a Pascal parent. (N. Wirth)

 

[misterT]

NorthGuy.. do you have an opinion about what is "good programming"?

 

[NorthGuy]

NorthGuy.. do you have an opinion about what is "good programming"?

I don't think I do. I'm always trying to think of all the details and handle even unprobable situations properly. I also try to design in such a way that I could easily extend the design. Someties I succeed, but often I don't and have to re-write to accomodate new features (either because I didn't think all the details through, or because I couldn't predict the direction of the development). I guess when I succeed and produce a code that is easy to work with that's been a good programming.

 

[nsaspook]

What is 'good programming' is a philosophical question. What's 'good' depends on the circumstances of the application and hardware resources but I think there is one overriding objective that gets lost in big projects, KISS.

"Make everything as simple as possible, but not simpler."
Albert Einstein

I can't say exactly what's 'good programming' but we all know what 'bad programming' does.