[yast-devel] Yast UI in Ruby: Formatting, Usage...
Hi, I've created a new pull request yesterday https://github.com/yast/yast-services-manager/pull/17/files that changes some ui-related code. Right now, it doesn't seem we have any agreement on how the code should look like in future. Some Examples ============= Table ----- https://github.com/kobliha/yast-services-manager/blob/fd1fe09c533a5f7b1f72eb... Everything on a separate line or should be something joint? ChangeWidget ------------ https://github.com/kobliha/yast-services-manager/blob/fd1fe09c533a5f7b1f72eb... One line rules them all or everything on its own line. From my POV, it actually doesn't matter that much. What matters is consistency within the rest of the code (or a library, Yast module...). Any opinions? Links to docu? Thx Lukas -- Lukas Ocilka, Cloud & Systems Management Department SUSE LINUX s.r.o., Praha -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
On Wed, 03 Jul 2013 10:29:37 +0200
Lukas Ocilka
Hi,
I've created a new pull request yesterday https://github.com/yast/yast-services-manager/pull/17/files that changes some ui-related code. Right now, it doesn't seem we have any agreement on how the code should look like in future.
Some Examples =============
Table ----- https://github.com/kobliha/yast-services-manager/blob/fd1fe09c533a5f7b1f72eb...
Everything on a separate line or should be something joint?
ChangeWidget ------------ https://github.com/kobliha/yast-services-manager/blob/fd1fe09c533a5f7b1f72eb...
One line rules them all or everything on its own line.
From my POV, it actually doesn't matter that much. What matters is consistency within the rest of the code (or a library, Yast module...).
Any opinions? Links to docu? Thx Lukas
It is nice, that ruby already have its own style guide, so we can just follow it - https://github.com/SUSE/style-guides/blob/master/Ruby.md If something is not clear, we can improve shared style guide, so devs who work on any ruby project feel confortable in yast in ruby. Question is if we should have DSL style for UI or common method calls. Josef -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
On 07/03/2013 10:49 AM, Josef Reidinger wrote:
It is nice, that ruby already have its own style guide, so we can just follow it - https://github.com/SUSE/style-guides/blob/master/Ruby.md
If something is not clear, we can improve shared style guide, so devs who work on any ruby project feel confortable in yast in ruby.
Question is if we should have DSL style for UI or common method calls.
Thanks Josef, So, it seems that UI definition is something similar to Array https://github.com/SUSE/style-guides/blob/master/Ruby.md#arrays or Hash https://github.com/SUSE/style-guides/blob/master/Ruby.md#hashes Both can actually use one-line and one-line-per-entry formatting depending on the Array, resp. Hash size. Is seems we don't need to be that strict. Lukas -- Lukas Ocilka, Cloud & Systems Management Department SUSE LINUX s.r.o., Praha -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
On Wed, 03 Jul 2013 11:03:54 +0200
Lukas Ocilka
On 07/03/2013 10:49 AM, Josef Reidinger wrote:
It is nice, that ruby already have its own style guide, so we can just follow it - https://github.com/SUSE/style-guides/blob/master/Ruby.md
If something is not clear, we can improve shared style guide, so devs who work on any ruby project feel confortable in yast in ruby.
Question is if we should have DSL style for UI or common method calls.
Thanks Josef,
So, it seems that UI definition is something similar to
Array https://github.com/SUSE/style-guides/blob/master/Ruby.md#arrays
or
Hash https://github.com/SUSE/style-guides/blob/master/Ruby.md#hashes
Both can actually use one-line and one-line-per-entry formatting depending on the Array, resp. Hash size.
Is seems we don't need to be that strict.
Lukas
For me it is more likely method calls https://github.com/SUSE/style-guides/blob/master/Ruby.md#method-calls and only question is if it is common calls or DSLs calls. Josef -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
Dne 3.7.2013 11:03, Lukas Ocilka napsal(a):
So, it seems that UI definition is something similar to
Array https://github.com/SUSE/style-guides/blob/master/Ruby.md#arrays
or
Hash https://github.com/SUSE/style-guides/blob/master/Ruby.md#hashes
As Josef pointed out, these are just method calls. This means that if we treat them as "non-DSL" in the style guide terminology, they should be written on one-line, and if that's not possible, like this (with a break before column 80): UI.ChangeWidget(Id(IDs::SERVICES_TABLE), Cell(service, 2), (running ? _('Active') : _('Inactive'))) I personally find this style of writing calls pretty much unreadable (this part of the style guide was a compromise), and I sometimes use a style like this (for calls in general, not only UI calls): UI.ChangeWidget( Id(IDs::SERVICES_TABLE), Cell(service, 2), (running ? _('Active') : _('Inactive')) ) That is, I put each parameter on a separate line. I think such occasional violations of the style guide are warranted by increased readability (note the style guide explicitly allows violations when that makes sense). This style of multiline calls is also what Y2R uses in all code it emits (because it was readable & simple to implement). This means we'll have a lot of code styled like this soon. ----- I propose to adopt a convention like this: * If it fits one line, write the call one line. * If it doesn't fit one line, write it in the "one line per parameter" style shown above. If you agree, there is a question of scope -- should this style be used for all calls in general, or just for UI calls? If we agree the scope should be all calls, we may also want to modify the style guide to explicitly allow that style (i.e. make it a SUSE-wide rule, not just YaST-wide). -- David Majda SUSE Studio developer http://susestudio.com/ -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
On 07/03/2013 11:38 AM, David Majda wrote:
Dne 3.7.2013 11:03, Lukas Ocilka napsal(a):
So, it seems that UI definition is something similar to
Array https://github.com/SUSE/style-guides/blob/master/Ruby.md#arrays
or
Hash https://github.com/SUSE/style-guides/blob/master/Ruby.md#hashes
As Josef pointed out, these are just method calls. This means that if we treat them as "non-DSL" in the style guide terminology, they should be written on one-line, and if that's not possible, like this (with a break before column 80):
UI.ChangeWidget(Id(IDs::SERVICES_TABLE), Cell(service, 2), (running ? _('Active') : _('Inactive')))
I personally find this style of writing calls pretty much unreadable (this part of the style guide was a compromise), and I sometimes use a style like this (for calls in general, not only UI calls):
UI.ChangeWidget( Id(IDs::SERVICES_TABLE), Cell(service, 2), (running ? _('Active') : _('Inactive')) )
That is, I put each parameter on a separate line.
I think such occasional violations of the style guide are warranted by increased readability (note the style guide explicitly allows violations when that makes sense).
This style of multiline calls is also what Y2R uses in all code it emits (because it was readable & simple to implement). This means we'll have a lot of code styled like this soon.
-----
I propose to adopt a convention like this:
* If it fits one line, write the call one line.
* If it doesn't fit one line, write it in the "one line per parameter" style shown above.
If you agree, there is a question of scope -- should this style be used for all calls in general, or just for UI calls? If we agree the scope should be all calls, we may also want to modify the style guide to explicitly allow that style (i.e. make it a SUSE-wide rule, not just YaST-wide).
Sounds good. Anyway, if we adjust the style guide, we should also cover multi-line prameters, e.g. Report::Error(_("Long multi-line text")), possibly in combination with function call nesting, e.g. Report::Error(sformat(_("Foo%1"),bar)). Both of these constructs are pretty common in YaST code. Jiri -- Regards, Jiri Srain Project Manager --------------------------------------------------------------------- SUSE LINUX, s.r.o. e-mail: jsrain@suse.com Lihovarska 1060/12 tel: +420 284 084 659 190 00 Praha 9 fax: +420 284 084 001 Czech Republic http://www.suse.com -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
Hello, I have a wish: On Jul 3 12:19 Jiri Srain wrote (excerpt):
Anyway, if we adjust the style guide, we should also
If you adjust the style guide, I would very much appreciate it, if you could add more code examples in particular more "bad" versus "good" examples. I did read the style guide but when each item had at least one "bad" versus "good" example, it would have been much easier to immediately understand what is meant. What I mean is something like "a picture (example) tells more than a thousand words". Kind Regards Johannes Meixner -- SUSE LINUX Products GmbH -- Maxfeldstrasse 5 -- 90409 Nuernberg -- Germany HRB 16746 (AG Nuernberg) GF: Jeff Hawn, Jennifer Guild, Felix Imendoerffer -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
participants (5)
-
David Majda -
Jiri Srain -
Johannes Meixner -
Josef Reidinger -
Lukas Ocilka