bugGNU Octave - Bugs: bug #57599, List of Octave code lines > 100...


bug #57599: List of Octave code lines > 100 characters

Submitter:  Rik <rik5>
Submitted:  Tue 14 Jan 2020 05:42:59 PM UTC
Category:  Coding Style and Maintenance Severity:  1 - Wish
Priority:  3 - Low Item Group:  Other
Status:  In Progress Assigned to:  None
Originator Name:  Open/Closed:  * Open
Release:  * dev Operating System:  * Any
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup

Jump to the original submission

Tue 23 Nov 2021 09:53:31 PM UTC, comment #12: 

I committed another changeset which reduces many long lines in the scripts/ directory.  See http://hg.savannah.gnu.org/hgweb/octave/rev/01de0045b2e3.

Rik <rik5>
Group administrator
Tue 23 Nov 2021 07:27:38 PM UTC, comment #11: 

I fixed the long @seealso lines in the scripts and libinterp directories in this changeset: http://hg.savannah.gnu.org/hgweb/octave/rev/81d26e8481a6.

Rik <rik5>
Group administrator
Thu 16 Jan 2020 09:43:19 PM UTC, comment #10: 

I reviewed the two Perl scripts and it would be fine to split long @seealso lines.

Rik <rik5>
Group administrator
Thu 16 Jan 2020 07:33:11 PM UTC, comment #9: 

They can be split, but in the past we didn't do it because each line represented a single calling form for the function which seemed like one continuous idea.

I don't think I would change the @deftypefn, but I would look at possibly splitting the @seealso links.  Those can also get very long.  Would need to check that this doesn't break munge-texi.pl or mk-doc-cache.pl.

Rik <rik5>
Group administrator
Thu 16 Jan 2020 06:20:50 PM UTC, comment #8: 

Oh, but the example shown right below that uses a continuation marker to split a long deftypefn declaration over multiple lines.  So they could be split, though I don't know whether we would have to adapt any of our build scripts or help functions that process the docstrings if we do decide to split them.

John W. Eaton <jwe>
Group administrator
Thu 16 Jan 2020 04:59:03 PM UTC, comment #7: 

The Texinfo manual says

     The '@deftypefn' command is the general definition command for
     functions and similar entities that may take arguments and that are
     typed.  The '@deftypefn' command is written at the beginning of a
     line and is followed on the same line by the category of entity
     being described, the type of the returned value, the name of this
     particular entity, and its arguments, if any.

so it appears that it must be on one line.

John W. Eaton <jwe>
Group administrator
Thu 16 Jan 2020 04:06:32 PM UTC, comment #6: 

Just curious:
Many deftypefn / deftypefnx function declarations in function headers are much longer than 80 chars, several much longer than 100. Do we keep them at their full length? (is that required for Texinfo?)

Philip Nienhuis <philipnienhuis>
Group Member
Wed 15 Jan 2020 05:28:50 PM UTC, comment #5: 

Don't think there is a concensus yet on the best line length to use.

Rik <rik5>
Group administrator
Wed 15 Jan 2020 06:04:49 AM UTC, comment #4: 

Is there already a consensus on the max. line length to use?
95 as proposed by Rik in the maintainers list?

Torsten Lilge <ttl>
Group Member
Tue 14 Jan 2020 10:09:36 PM UTC, comment #3: 

New file uploaded with correct filenames.

(file #48230)

Rik <rik5>
Group administrator
Tue 14 Jan 2020 10:02:35 PM UTC, comment #2: 

Let me take a look.  It sometimes happens with the Perl construct I used that the file name is off-by-one.

Rik <rik5>
Group administrator
Tue 14 Jan 2020 09:57:51 PM UTC, comment #1: 

I'm not sure what happened, but the output attached here shows lines from mx-op-defs.h with the name child-list.cc.  Similarly, lines from Faddeeva.cc with the name blas-xtra/xerbla.cc.

John W. Eaton <jwe>
Group administrator
Tue 14 Jan 2020 05:42:59 PM UTC, original submission:  

Attached is a list of of very long lines in Octave (> 100 characters).  The liste includes the file, line number, and the line for inspection.

Ideally, some of these could be shortened to something more managable.  However, there are many cases where the code belongs to a third party and should not be adapted to Octave's coding conventions so that merges with upstream can be done more easily.  Examples include Faadeeva.cc and anything in the libqterminal/ directory.

Rik <rik5>
Group administrator


(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:

Attached Files
file #48230:  100.lines added by rik5 (193KiB - application/octet-stream)


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -email is unavailable- added by ttl (Posted a comment)
  • -email is unavailable- added by jwe (Posted a comment)
  • -email is unavailable- added by rik5 (Submitted the item)

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only project members can vote.


    Follow 7 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2021-11-23 rik5 StatusNone In Progress
    2021-11-22 jwe CategoryNone Coding Style and Maintenance
    2020-01-14 rik5 Attached File- Added 100.lines, #48230
    2020-01-14 rik5 Attached File#48228 Removed
    2020-01-14 rik5 Severity3 - Normal 1 - Wish
        Priority5 - Normal 3 - Low
    2020-01-14 rik5 Attached File- Added 100.lines, #48228

    Back to the top

    Powered by Savane 3.12.
    Corresponding source code