Mailinglist Archive: yast-devel (121 mails)

< Previous Next >
[yast-devel] Changing the Attitude to Coding YaST
  • From: Lukas Ocilka <lukas.ocilka@xxxxxxx>
  • Date: Wed, 08 Jun 2011 15:16:35 +0200
  • Message-id: <>
Hash: SHA1

Yasties, Developers and Friends,

According to the feedback I've got recently and what I've been feeling
for a longer time, there is a chance to make YaST development cleaner,
simpler and more enjoyable just with little tricks learned from the
other projects we've been working on recently.

Here you can see a list of unsorted ideas that came into my mind
thinking about the other project and reusing experience with them in the
YaST development:

Code Reusability
- - Usually the code is written for one purpose, but maybe we should
start thinking before the development: Isn't the code reusable from
anywhere else? Can the code be more generic? Think about CWM.
- - Additionally, a lot of the code is in "include"d files or even in
"client"s which makes the code almost impossible to be tested. That's
also why we get syntax and/or runtime errors.
- - Fix|Easy: Develop code in reusable libraries and write simple and
understandable tests.

- - Connected to the previous point. Most of the current code is not
tested because it actually cannot be tested.
- - On the other hand, sometimes we think that writing testsuites is for
dummies. But untested code causes bugs that need to be fixed later
and thus is doesn't save the time at all.
- - Fix|Medium: Write tests, make sure they are called during build.

Coding Standards
- - The code should be not only understandable to ourselves but also to
the others. Using the same coding standards make it easier to
understand the code structure, parameters, expected return value and
so long.
- - Examples:
* Package::IsValid(package) -> returns boolean (maybe only Valid())
* Package::Install(package) -> do you need to read any documentation?
* Using hashes with parameters instead of twelve parameters, eight of
them optional
* Indentation
* No more "include"s if not necessary
* Useful comments
* Useful documentation of all the public functions
* ... other ideas? ...
- - Fix|Medium: Define the standards and use them (let's learn from other

- - When the code has tests and it's mostly in compiled libraries, it's
quite easy for more developers to work on the same project in the
same time. The only thing they need to define is the API and using
the same standards they can understand the API almost instantly.
- - Better cooperation is usually useful when someone needs help from the
others: too many features and bugs and to few time.
- - Fix|Depends: ...

Code Reviews
- - In the SLMS team, we've found out that all the commits should be
reviewed by someone else. This helps to identify potential issues in
time. All the commits are public anyway.
- - Fix|Easy to Medium: Either someone is always assigned to review
everyone's code (takes too much time) or developers usually check
code of someone else only.

Shared Task List
- - There are often even smaller tasks that need to be done by anyone in
the team but they don't have their priority high enough (so called
easy-hacks) - and that's why we forget them quite easily.
- - Fix|Easy to Medium: Use some of the task managers, e.g., anyone can pick a task and try to
implement / fix it.

I believe that you have other ideas how to improve the development - how
to make the development and maintenance easier for you and/or the
others. Or you maybe have an opinion on the ideas I just presented.
Share them with us, please! :)

Thanks in advance and Bye

- --

Lukas Ocilka, Appliances Department, SUSE LINUX s.r.o.
MD: Jeff Hawn, Jennifer Guild, Alena Hendrichova
Version: GnuPG v2.0.16 (GNU/Linux)
Comment: Using GnuPG with SUSE -

To unsubscribe, e-mail: yast-devel+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: yast-devel+help@xxxxxxxxxxxx

< Previous Next >