Re: [darktable-dev] Code reformatting...

2023-01-23 Thread Pascal Obry
Le lundi 23 janvier 2023 à 22:30 +0100, Heiko Bauke a écrit :
> Also working with code in Github, 
> Bitbucket etc., e.g. during code review, becomes rather uncomfortable
> when the column width exceeds 80 characters significantly.

Ok, 90 is still fine by me.

-- 
  Pascal Obry /  Magny Les Hameaux (78)

  The best way to travel is by means of imagination

  http://photos.obry.net

  gpg --keyserver keys.gnupg.net --recv-key F949BD3B

___
darktable developer mailing list
to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org



Re: [darktable-dev] Code reformatting...

2023-01-23 Thread Pascal Obry
Le lundi 23 janvier 2023 à 22:12 +0100, Matthias Andree a écrit :
> 
> While the idea is sound, 80 character wide lines seem so... 1980's.
> Do
> people still need to read and edit darktable source code on 640x480
> displays?

This has nothing to do with display size. Do you know why news paper
has small columns? Because it is faster to read, that is, the time to
go from the end of line to the start of the new is far easier if the
width is not too large.

Also, try a side-by-side diff with long lines. And try reviewing code
in GitHub where you have to scroll the diff window to see the end of
line...

Readability is important and I do feel this is far better than current
layout.

-- 
  Pascal Obry /  Magny Les Hameaux (78)

  The best way to travel is by means of imagination

  http://photos.obry.net

  gpg --keyserver keys.gnupg.net --recv-key F949BD3B

___
darktable developer mailing list
to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org



Re: [darktable-dev] Code reformatting...

2023-01-23 Thread Heiko Bauke

Hi,

Am 23.01.23 um 22:12 schrieb Matthias Andree:

Am 23.01.23 um 08:40 schrieb Pascal Obry:
While the idea is sound, 80 character wide lines seem so... 1980's. Do
people still need to read and edit darktable source code on 640x480
displays?


today's developers have not only wider screens than in the 1980ies with 
higher resolution.  They also use different tools, e.g., graphical 
three-way-merge tools (which usually show three source code versions 
next to each other).  Therefore, I would ague that the maximal source 
code width, that one can comfortably work with, is somewhere between 72 
and 96 characters even today.  Also working with code in Github, 
Bitbucket etc., e.g. during code review, becomes rather uncomfortable 
when the column width exceeds 80 characters significantly.



Heiko

--
-- Number Crunch Blog @ https://www.numbercrunch.de
--  Cluster Computing @ https://www.clustercomputing.de
--  Social Networking @ https://www.researchgate.net/profile/Heiko_Bauke

___
darktable developer mailing list
to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org



Re: [darktable-dev] Code reformatting...

2023-01-23 Thread Heiko Bauke

Dear Pascal,

Am 23.01.23 um 08:40 schrieb Pascal Obry:


Hello devs,

As we are not ready to have an automatic reformatting of the code I
have started at least making the function headers a bit more readable.

From:

void dt_gui_presets_show_edit_dialog(const char *name_in, const char 
*module_name, int rowid,
  GCallback final_callback, gpointer data, 
gboolean allow_name_change,
  gboolean allow_desc_change,
  gboolean allow_remove, GtkWindow *parent)

To:

void dt_gui_presets_show_edit_dialog(const char *name_in,
  const char *module_name,
  const int rowid,
  GCallback final_callback,
  gpointer data,
  const gboolean allow_name_change,
  const gboolean allow_desc_change,
  const gboolean allow_remove,
  GtkWindow *parent)

This is to be done only if the function header does not fit in a single
line of 80 characters.

When I work on a file I'll try to do this change in a separate commit
"Minor reformatting" and I encourage all devs to do the same.

This will make the code a bit more readable and the type/name of the
parameters to stand out a bit more.


I think it is very valuable to have consistent code formatting within a 
common code base.  Though, I wonder why these manual reformattings? 
There is a .clang-format file in dt's source root directory.  Are these 
manual "minor reformattings" compatible with the formatting rules as 
defined in .clang-format?



Regards,

Heiko


--
-- Number Crunch Blog @ https://www.numbercrunch.de
--  Cluster Computing @ https://www.clustercomputing.de
--  Social Networking @ https://www.researchgate.net/profile/Heiko_Bauke

___
darktable developer mailing list
to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org



Re: [darktable-dev] Code reformatting...

2023-01-23 Thread Matthias Andree

Am 23.01.23 um 08:40 schrieb Pascal Obry:

Hello devs,

As we are not ready to have an automatic reformatting of the code I
have started at least making the function headers a bit more readable.

From:

void dt_gui_presets_show_edit_dialog(const char *name_in, const char 
*module_name, int rowid,
  GCallback final_callback, gpointer data, 
gboolean allow_name_change,
  gboolean allow_desc_change,
  gboolean allow_remove, GtkWindow *parent)

To:

void dt_gui_presets_show_edit_dialog(const char *name_in,
  const char *module_name,
  const int rowid,
  GCallback final_callback,
  gpointer data,
  const gboolean allow_name_change,
  const gboolean allow_desc_change,
  const gboolean allow_remove,
  GtkWindow *parent)

This is to be done only if the function header does not fit in a single
line of 80 characters.

When I work on a file I'll try to do this change in a separate commit
"Minor reformatting" and I encourage all devs to do the same.

This will make the code a bit more readable and the type/name of the
parameters to stand out a bit more.

Thanks,


While the idea is sound, 80 character wide lines seem so... 1980's. Do
people still need to read and edit darktable source code on 640x480
displays?

___
darktable developer mailing list
to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org