Re: 80-column width [WAS: Re: indent]
On Fri, 2007-03-09 at 15:46 -0500, Chris Shoemaker wrote:
Let me speak up in favor of the 80-char limit. However, I'm okay with
treating it as strongly encouraged rather than rigorously enforced.
I think after discussion in #gnucash that we've come to consensus that
the goal is an 80-column line width, but that it's not a hard rule.
I think breaking after '(' is a good idea, as well, and should be part
of the style.
I mentioned at the time that it'd be interesting to know what the
natural width is. Not rigorously, just looking at the number of
line-ending =s after re-formatting with -l{80,85,90,95,100}, we see:
src/engine/Transaction.c
txn-80.c: 4
txn-85.c: 2
txn-90.c: 2
txn-95.c: 1
txn-100.c: 1
src/gnome/gnc-plugin-page-register.c:
register-80.c: 12
register-85.c: 6
register-90.c: 6
register-95.c: 2
register-100.c: 1
--
...jsled
http://asynchronous.org/ - a=jsled;b=asynchronous.org; echo [EMAIL PROTECTED]
signature.asc
Description: This is a digitally signed message part
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: indent
On Sat, 2007-03-10 at 14:57 +0100, Christian Stimming wrote: (If I speak for myself, I rather prefer -bl -bli0 i.e. the braces after if on a new line, but I know this style is used only by a minority and in this case I think the benefit of a uniform style outweighs by far the discomfort of not seeing my individual preferences applied.) Agreed. I certainly prefer the '-bl -bli0' style, but it's far more important that we're consistent. So: When will the One Great Indentation Commit happen in SVN, who will do it, and how do we enforce this style for future commits? The timing argument is similar to the Great Renaming we've discussed ... probably best immediately before a public pre-release series, such as the upcoming 2.1.0. At that point, any outstanding changes are minimized, and we're at a point where we won't need to back-port fixes to a previous release line with a different style. Part of the motivation for doing the Great Renaming at that point is to minimize the amount of public stack traces from testing of builds that are contain the old names. That argument doesn't really apply here. The bigger issue is the other major pending changes right now: the gobject-dev, gda-dev and modules-cleanup branches. I suppose each of them could be separately ident-ified, and then any cross-merging that needed to occur could simply skip the reformatting changeset. Of course, they'd all want to merge up to the revision of pre-reformatted trunk before being re-formatted themselves. A bit messy, but I don't think it's horrible with communication. I think David should do the reformatting. I'd imagine editor configuration is the primary way the formatting will occur; I've not yet come up with the proper emacs incantations for the style. Perhaps a 'gnucash-c-mode' for convenience. We could add emacs- or vi-style mode lines to individual files as well, but if devs already have their editor configured, that becomes redundant. HACKING should be updated to include the details. Social mechanisms are probably the best enforcement. I don't think we want to automate running indent on every commit or anything. -- ...jsled http://asynchronous.org/ - a=jsled;b=asynchronous.org; echo [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [dev] Re: indent
On Sat, 10 Mar 2007, Peter Selinger wrote: in lib/goffice-0.0.4/goffice/utils/go-regression.c. I don't think This mass indenting should not touch any external libraries that are included with gnucash. goffice was removed I guess, but if there are any others don't indent them. They should be a close to upstream as possible. -Ariel ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: indent
Am Freitag, 9. März 2007 05:46 schrieb David Hampton: There's been some discussion on IRC about using the indent program to reformat the sources into something consistent from file to file. Of the above list of options, the ones I feel strongly about are lining up continued lines at parentheses (-lp), the space-after-keyword group (saf, -sai, -saw), and the cuddling-of-braces group (-br, -ce, -cdw). I feel most strongly about this last group. Sounds fine with me. (If I speak for myself, I rather prefer -bl -bli0 i.e. the braces after if on a new line, but I know this style is used only by a minority and in this case I think the benefit of a uniform style outweighs by far the discomfort of not seeing my individual preferences applied.) So: When will the One Great Indentation Commit happen in SVN, who will do it, and how do we enforce this style for future commits? Regards, Christian ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: indent
Josh Sled wrote:
On Fri, 2007-03-09 at 02:21 -0400, Peter Selinger wrote:
I also recommend
-T ExampleType
for every 'typedef', so that you get:
:( We have nearly a thousand typedefs in the code some are relatively
anonymous, but most aren't... I wonder if there's a way to say '-T *',
or something similar?
There is no way to say '-T *', because indent cannot figure out which
identifiers are type names (if there were, then there would be no need
for '-T' options). Only identifiers of the form *_t are automatically
recognized as types (in addition to some standard names such as int,
but not, for example, FILE).
Actually, there are 1580 typedef's in the code. I guess it's best to
read the options of indent from a file anyway, so perhaps their
great number isn't a real problem. A list is appended below.
One strange special case is
typedef struct {
DOUBLE min_x;
DOUBLE max_x;
DOUBLE min_y;
DOUBLE max_y;
DOUBLE mean_y;
} SUFFIX(point_cloud_measure_type);
in lib/goffice-0.0.4/goffice/utils/go-regression.c. I don't think
indent will be able to understand this one.
There are also some type identifiers (for indent purposes) that are
declared with #define instead of typedef, for example
#define DOUBLE double
in lib/goffice-0.0.4/goffice/utils/go-regression.c. Ideally, these
should have -T options too, but I didn't attempt to make a list of
them. Finally, there is stuff, such as FILE, defined in header files
that I didn't scan.
gfec_error_handler
GNCComponentRefreshHandler
GNCComponentCloseHandler
GNCComponentFindHandler
GNCComponentHandler
GNCDruidNew
GNCDruidProviderCB
GNCDruidProviderNew
QofSessionCB
GNCOptionGetUIValue
GNCOptionSetUIValue
GNCOptionSetSelectable
GNCOptionChangeCallback
GncGconfGeneralCb
GncGconfGeneralAnyCb
xaccGetBalanceFn
xaccGetBalanceInCurrencyFn
xaccGetBalanceAsOfDateFn
SplitCallback
TransactionCallback
gnc_engine_init_hook_t
pathGenerator
AccountCallback
Predicate
GNCProgressCancelFunc
GncHierarchyDruidFinishedCallback
GNCSearchCallback
GNCSearchResultCB
GNCSearchNewItemCB
GNCSearchFree
GNCSearchSelectedCB
GNCSearchCB
GNCSearchCoreNew
AccountBoolCB
gnc_commodity_help_callback
GNCOptionWinCallback
GNCOptionUISetWidget
GNCOptionUISetValue
GNCOptionUIGetValue
GNCDisplayListCB
gnc_xfer_dialog_cb
GNCOptionCallback
GNCOptionCallback
GD_Getter_Func
GD_Setter_Func
GncDialogCallback
GncDialogSetter
GncDialogGetter
GncDialogFiller
GNCShutdownCB
GNCGeneralSelectGetStringCB
GNCGeneralSelectNewSelectCB
GncHTMLUrltypeCB
GncHTMLFlyoverCB
GncHTMLLoadCB
GncHTMLButtonCB
GncHTMLObjectCB
GncHTMLActionCB
GncHTMLStreamCB
GncHTMLUrlCB
gnc_html_history_destroy_cb
GncMainWindowFunc
GncTreeViewAccountColumnSource
GncTreeViewAccountColumnTextEdited
gnc_tree_view_account_filter_func
gnc_tree_view_commodity_ns_filter_func
gnc_tree_view_commodity_cm_filter_func
renderer_toggled
gnc_tree_view_price_ns_filter_func
gnc_tree_view_price_cm_filter_func
gnc_tree_view_price_pc_filter_func
GNCSearchParamFcn
GncHTTPRequestCB
GsfXMLInUnknownFunc
GNCEngineEventHandler
qof_book_mergeRuleForeachCB
QofBePercentageFunc
QofBackendOptionCB
QofBookFinalCB
QofBookDirtyCB
QofCollectionForeachCB
QofBookMergeRuleForeachCB
QofAccessFunc
QofSetterFunc
QofCompareFunc
QofSortFunc
QofClassForeachCB
QofParamForeachCB
QofEventHandler
QofEntityForeachCB
QofLogCB
QofForeachCB
QofForeachTypeCB
QofForeachBackendTypeCB
QueryPredDataFree
QueryPredicateCopyFunc
QueryToString
QueryPredicateEqual
query_string_getter
query_date_getter
query_numeric_getter
query_glist_getter
query_guid_getter
query_int32_getter
query_int64_getter
query_double_getter
query_boolean_getter
query_char_getter
query_kvp_getter
query_collect_getter
query_choice_getter
QofQueryPredicateFunc
QofPercentageFunc
gxpf_callback
countCallbackFn
sixtp_start_handler
sixtp_before_child_handler
sixtp_after_child_handler
sixtp_end_handler
sixtp_characters_handler
sixtp_result_handler
sixtp_fail_handler
sixtp_push_handler
GenericLookup_t
GNCLedgerDisplayDestroy
GNCLedgerDisplayGetParent
GNCLedgerDisplaySetHelp
SRGetParentCallback
CellCreateFunc
CellSetValueFunc
CellEnterFunc
CellModifyVerifyFunc
CellDirectUpdateFunc
CellLeaveFunc
CellRealizeFunc
CellMoveFunc
CellDestroyFunc
g_table_entry_constructor
g_table_entry_destroyer
RecnCellStringGetter
RecnCellConfirm
TableCursorRefreshCB
TableRedrawHelpCB
TableDestroyCB
TableMoveFunc
TableTraverseFunc
TableGetEntryHandler
TableGetLabelHandler
TableGetHelpHandler
TableGetCellIOFlagsHandler
TableGetFGColorHandler
TableGetBGColorHandler
TableGetCellBorderHandler
TableConfirmHandler
TableSaveCellHandler
TableSaveHandler
VirtCellDataAllocator
VirtCellDataDeallocator
VirtCellDataCopy
GetPopupHeight
PopupAutosize
PopupSetFocus
PopupPostShow
PopupGetWidth
VirtualLocationMatchFunc
GOFileOpenerProbeFunc
GOFileOpenerOpenFunc
GOFileOpenerOpenFuncWithEnc
GOFileSaverSaveFunc
GOPluginServiceCreate
GodTextModelParagraphForeachCallback
GogEnumFunc
GogGuruRegister
GogDataDuplicator
GogThemeStyleMap
GOMSParserHandleAtom
Re: indent
Am Samstag, 10. März 2007 19:28 schrieb Peter Selinger: On Fri, 2007-03-09 at 02:21 -0400, Peter Selinger wrote: I also recommend -T ExampleType for every 'typedef', so that you get: There is no way to say '-T *', because indent cannot figure out which identifiers are type names Actually, there are 1580 typedef's in the code. I guess it's best to read the options of indent from a file anyway, so perhaps their great number isn't a real problem. A list is appended below. Actually your list still includes the typedefs of goffice, which has (eventually, fortunately, luckily) been removed from SVN-trunk yesterday. Could you recreate that list with SVN trunk r15702 or higher? Thanks a lot. Christian ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: indent
Christian Stimming wrote: Am Samstag, 10. Maerz 2007 19:28 schrieb Peter Selinger: On Fri, 2007-03-09 at 02:21 -0400, Peter Selinger wrote: I also recommend -T ExampleType for every 'typedef', so that you get: There is no way to say '-T *', because indent cannot figure out which identifiers are type names Actually, there are 1580 typedef's in the code. I guess it's best to read the options of indent from a file anyway, so perhaps their great number isn't a real problem. A list is appended below. Actually your list still includes the typedefs of goffice, which has (eventually, fortunately, luckily) been removed from SVN-trunk yesterday. Could you recreate that list with SVN trunk r15702 or higher? Thanks a lot. Here is the list for -r15706: PopBox select_info SheetBlockStyle SheetBlock GnucashSheet GnucashRegister VirtualLocationMatchFunc GnucashSheetClass GnucashRegisterClass GNCDatePicker GNCDatePickerClass FindSelectionData GncItemList GncItemListClass TextDrawInfo GncScrolledWindow GncScrolledWindowClass GnucashItemCursor GnucashCursor GnucashItemCursorClass GnucashCursorClass GetPopupHeight PopupAutosize PopupSetFocus PopupPostShow PopupGetWidth PopupToggle GncItemEdit GncItemEditClass PopBox GnucashGrid GnucashGridClass GncHeader GncHeaderClass WidthNode CellDimensions BlockDimensions GNCHeaderWidths DupTransDialog SRSaveData GNCLedgerDisplay GNCLedgerDisplayDestroy GNCLedgerDisplayGetParent GNCLedgerDisplaySetHelp GNCLedgerDisplayType RegisterColor SplitRegisterType SplitRegisterStyle CursorClass SplitRegisterColors SplitRegister SRInfo SRGetParentCallback CellBuffer CellBlock GTable g_table_entry_constructor g_table_entry_destroyer NumCell ComboCell PriceCell TableLayout CursorBuffer gncTableTraversalDir TableMoveFunc TableTraverseFunc TableControl VirtualCellLocation VirtualLocation FormulaCell DateCell HandlerNode BasicCell CellCreateFunc CellSetValueFunc CellEnterFunc CellModifyVerifyFunc CellDirectUpdateFunc CellLeaveFunc CellRealizeFunc CellMoveFunc CellDestroyFunc CellAlignment QuickFillCell CellIOFlags PhysicalCellBorderLineStyle PhysicalCellBorders TableGetEntryHandler TableGetLabelHandler TableGetHelpHandler TableGetCellIOFlagsHandler TableGetFGColorHandler TableGetBGColorHandler TableGetCellBorderHandler TableConfirmHandler TableSaveCellHandler TableSaveHandler VirtCellDataAllocator VirtCellDataDeallocator VirtCellDataCopy TableModel CheckboxCell RecnCellStringGetter RecnCellConfirm RecnCell VirtualCell Table TableCursorRefreshCB TableRedrawHelpCB TableDestroyCB TableGUIHandlers CellRecord CellFactory GncGconfGeneralCb GncGconfGeneralAnyCb GncGMapFunc tran_data act_data com_data pricedb_data fsParseData gxpf_callback gxpf_data QofBookFileType FileBackend GncExampleAccount sixtp_child_result sixtp_start_handler sixtp_before_child_handler sixtp_after_child_handler sixtp_end_handler sixtp_characters_handler sixtp_result_handler sixtp_fail_handler sixtp_push_handler sixtp sixtp_handler_type sixtp_child_result_type sixtp_sax_data TimespecParseInfo sixtp_stack_frame sixtp_parser_context GNCParseErr GNCParseStatus CommodityParseInfo CommodityLookupParseInfo iconv_item_type push_data_type load_counter sixtp_gdv2 countCallbackFn GncXmlDataType_t gnc_template_xaction_data conv_type QofMap DbInfo CommodityDeleteInfo QueryTestData UpdateTestData TransResolveInfo QueryData AcctEarliest sqlEscape PGBackend AccessMode store_data_t sqlQuery Event DeleteTransInfo SplitResolveInfo pgendVersion sqlBuild_QType sqlBuilder AccountResolveInfo GetAccountData Checkpoint QIFAccountPickerDialog GncPluginQifImportPrivate GncDruidTest QIFDruidPage GncPluginQifImport GncPluginQifImportClass CommodityDruid CommodityDruidPage GncPluginOfx GncPluginOfxClass GncPluginOfxPrivate parse_helper_t qif_merge_t QifObject QifData QifAccount QifCategory QifClass QifSecurity QifTxn QifSplit QifInvstTxn QifType QifHandler QifContext QifLine QifRecnFlag QifError QifAction my_ymd_t HBCIInitialInfo PMon_state GNCInteractor GncPluginHbciPrivate TemplateListColumns GncPluginHbci GncPluginHbciClass HBCITransDialog GNC_HBCI_Transtype GNCTransTempl DaterangeInfo split_record GncPluginLogreplay GncPluginLogreplayClass GncPluginLogreplayPrivate GNCImportProvFormatGnome GNCImportProvFormatGnomeClass GNCImportMainMatcher GncImportMatchMap GNCImportFormatCB GNCImportFormatCBClass GNCImportTransInfo GNCImportMatchInfo GNCImportAction GNCImportSettings GNCImportMatchPicker GNCImportDescFormat GNCImportDescFormatClass GncImportFormat GNCModule GNCModuleInfo GNCLoadedModule GncPluginStylesheets GncPluginStylesheetsClass GncPluginStylesheetsPrivate ss_info gnc_column_view_edit gnc_report_window GncPluginPageReportPrivate StyleSheetDialog GncPluginPageReport GncPluginPageReportClass GncTaxTable GncTaxTableEntry GncAccountValue GncAmountType GncTaxIncluded GncJob GncOwner GncOwnerType GncInvoice EntryList GncVendor GncEntry GncEntryPaymentType GncDiscountHow AccountValueList GncCustomer GncBillTerm
80-column width [WAS: Re: indent]
On Thu, 2007-03-08 at 23:46 -0500, David Hampton wrote: -l80 Line width of 80. This one I find problematic. I understand the arguments for it, and have made them myself. But identifiers and type names are just too long these days. An 80-char limit can cause frequent and unnatural line-breaking; I think 100-char limit is more realistic. I do think a 80-char limit is a good guideline ... but an unbroken (e.g.) 95-character line is better than an 80-character line followed by a 15-character line. See the attached example of over-zealous wrapping differences of gnc-plugin-page-register.c. If we persist, I think we should have a convention for where the '=' goes, and that is at the beginning of the next line (like other continuing operators). Note that I think -lc80 is very reasonable, though. -- ...jsled http://asynchronous.org/ - a=jsled;b=asynchronous.org; echo [EMAIL PROTECTED] [EMAIL PROTECTED] [~/stuff/proj/gnucash/src-trunk]$ egrep -n -A1 = *$ ~/tmp/register-80.c ; egrep -n -B1 ^ *= ~/tmp/register-80.c 381:static guint gnc_plugin_page_register_n_actions = 382-G_N_ELEMENTS(gnc_plugin_page_register_actions); -- 535:gnc_plugin_page_register_type = 536-g_type_register_static(GNC_TYPE_PLUGIN_PAGE, -- 640:gnc_plugin_class-update_edit_menu_actions = 641-gnc_plugin_page_register_update_edit_menu; -- 669:action_group = 670-gnc_plugin_page_create_action_group(parent, -- 877:priv-component_manager_id = 878-gnc_register_gui_component(GNC_PLUGIN_PAGE_REGISTER_NAME, -- 948:priv-gsr-window = 949-GTK_WIDGET(gnc_window_get_gtk_window(GNC_WINDOW(window))); -- 1080:use_double_line = 1081-g_key_file_get_boolean(key_file, group_name, KEY_DOUBLE_LINE, error); -- 1126:account = 1127- gnc_account_lookup_by_full_name(gnc_book_get_root_account(book), -- 1844:name = 1845-g_strconcat(account_name, , _(and subaccounts), - , -- 2457:window = 2458- gnc_window_get_gtk_window(GNC_WINDOW(GNC_PLUGIN_PAGE(page)-window)); -- 3029:label = 3030- gnc_plugin_page_register_get_tab_name(GNC_PLUGIN_PAGE(page)); -- 3050:visible_page = 3051-gnc_main_window_get_current_page(GNC_MAIN_WINDOW(window)); [EMAIL PROTECTED] [~/stuff/proj/gnucash/src-trunk]$ egrep -n -A1 = *$ ~/tmp/register-100.c 781:priv-component_manager_id = 782-gnc_register_gui_component(GNC_PLUGIN_PAGE_REGISTER_NAME, signature.asc Description: This is a digitally signed message part ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: indent
On Fri, 2007-03-09 at 01:17 -0500, Chris Shoemaker wrote: I would recommend adding -ss, and I would have defaulted to -cli0, which is also KR, but I don't feel strongly about it. +1 on -ss . -- ...jsled http://asynchronous.org/ - a=jsled;b=asynchronous.org; echo [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: indent
On Fri, 2007-03-09 at 02:21 -0400, Peter Selinger wrote: I also recommend -T ExampleType for every 'typedef', so that you get: :( We have nearly a thousand typedefs in the code some are relatively anonymous, but most aren't... I wonder if there's a way to say '-T *', or something similar? -- ...jsled http://asynchronous.org/ - a=jsled;b=asynchronous.org; echo [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: 80-column width [WAS: Re: indent]
On Fri, Mar 09, 2007 at 10:16:47AM -0500, Josh Sled wrote: On Thu, 2007-03-08 at 23:46 -0500, David Hampton wrote: -l80Line width of 80. This one I find problematic. I understand the arguments for it, and have made them myself. But identifiers and type names are just too long these days. An 80-char limit can cause frequent and unnatural line-breaking; I think 100-char limit is more realistic. I do think a 80-char limit is a good guideline ... but an unbroken (e.g.) 95-character line is better than an 80-character line followed by a 15-character line. See the attached example of over-zealous wrapping differences of gnc-plugin-page-register.c. If we persist, I think we should have a convention for where the '=' goes, and that is at the beginning of the next line (like other continuing operators). Let me speak up in favor of the 80-char limit. However, I'm okay with treating it as strongly encouraged rather than rigorously enforced. I'm sympathetic that, sometimes, overrunning the 80-char limit is less unreadable than some of the obvious line-wrapping alternatives. In order to make the overruns as rare as practical, I think we should: 1) encourage the use of the static functions prefixed with the acronym-ed name of their gtype receiver. e.g. gppr_close_helper() instead of gnc_plugin_page_register_close_helper(); and 2) encourage wrapping after the open parenthesis, e.g.: foo_is_a_short_name = but_these_names_are_rather_too_long( argument1, argument2, argument3, argument4); Do the ident settings permit 2)? -chris ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: 80-column width [WAS: Re: indent]
On Fri, 2007-03-09 at 15:46 -0500, Chris Shoemaker wrote: 2) encourage wrapping after the open parenthesis, e.g.: foo_is_a_short_name = but_these_names_are_rather_too_long( argument1, argument2, argument3, argument4); Do the ident settings permit 2)? -nlp will tell indent not to indent to the open parenthesis. I'm not sure if there is an argument to to force a carriage return after an open parenthesis. With -nlp, this may look like the above, or may look like this: foo_is_a_short_name = but_these_names_are_rather_too_long(argument1, argument2, argument3, argument4); It would depend on whether or not argument1 runs over the line width. David ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
indent
There's been some discussion on IRC about using the indent program to
reformat the sources into something consistent from file to file. I'd
like to propose the following options as a starting point for
discussion. I think some of these options will be agreed upon by all,
and I'm sure others will be contentious. :-)
Indentation
-nutNo tabs. Indentation is done with spaces.
-i4 Add four spaces for each indent level
-ci4Continuation lines are indented by four spaces
-cli4 Case labels are indented by four spaces
-ppi4 Nested pre-processor defines are indented by four spaces
-nbcDo not force newlines after commas in declarations (default)
-nbfda Don´t put each argument in a function declaration
on a separate line (default)
-lp Line up continued lines at parentheses (default)
-pslPut the type of a procedure on the line before its name.
-bboPrefer to break long lines before boolean operators.
Blank Lines
-nsob Do not swallow optional blank lines (default)
-badForce a blank line after a declaration.
-bbbForce a blank line before a block comment.
-bapForce blank lines after procedure bodies.
Comments
-fcaReformat all comments except those starting in column 1
-fc1Reformat comments starting in column 1
-sc Continuation lines in a comments start with a '*'
Statements
-npcs Do not put space after the function in function calls.
-nprs Do not put a space after every ´(´ and before every ´)´.
-ncsDo not put a space after cast operators.
-safPut a space after each for.
-saiPut a space after each if.
-sawPut a space after each while.
-brsPut braces on struct declaration line.
-br Put braces on line with if, etc.
-ce Cuddle else and preceeding `}´.
-cdwCuddle while of do {} while; and preceeding `}´.
Other
-l80Line width of 80.
Attached is a small source file formatted with the above options.
Let the discussion begin. :-)
Of the above list of options, the ones I feel strongly about are lining
up continued lines at parentheses (-lp), the space-after-keyword group
(saf, -sai, -saw), and the cuddling-of-braces group (-br, -ce, -cdw). I
feel most strongly about this last group. The parts of an if/then/else
statement are clearly delineated by the indentation of the keywords vs.
the indentation of the code blocks. I believe it a complete waste to
additionally add vertical separation my making the else take up three
lines. One for a closing parenthesis, one for the word else, and one
for an opening parenthesis. Maybe that's just me.
What do the rest of the developers think?
David
#ifdef A
#ifdef B
#define C
#else
#define D
#endif
#else
#define E
#endif
/***
* *
***/
struct foo {
int i, j;
char *s;
};
char *a;
char *b;
/* kssf */
char *g;
/*
* Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod
* tempor incididunt ut labore et dolore magna aliqua.
. */
static void
example(int foo, char *bar, ExampleType * aligned_here)
{
Foo *bar = { 1, foo }; /* lorem ipsum */
for (int i = 0; i 10; i++) {
if (is_is_a_reasonable_value(i)
(i 10 || i 11)) {
// ...
} else {
break;
}
}
this_is_a_long_function_name(and_this, function, has_a_very, large,
number_of, arguments);
switch (foobar) {
case 0:
z = is_is_a_reasonable_value(i);
break;
default:
z = !is_is_a_reasonable_value(i);
break;
}
while (TRUE) {
// ...
}
do {
// ...
} while (TRUE);
}
static void
another_example(int and_this, char *function, ExampleType * has_a_very,
char *large, double number_of, int arguments)
{
}
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: indent
On Thu, Mar 08, 2007 at 11:46:53PM -0500, David Hampton wrote:
There's been some discussion on IRC about using the indent program to
reformat the sources into something consistent from file to file. I'd
like to propose the following options as a starting point for
discussion. I think some of these options will be agreed upon by all,
and I'm sure others will be contentious. :-)
Indentation
-nut No tabs. Indentation is done with spaces.
-i4 Add four spaces for each indent level
-ci4 Continuation lines are indented by four spaces
-cli4 Case labels are indented by four spaces
-ppi4 Nested pre-processor defines are indented by four spaces
-nbc Do not force newlines after commas in declarations (default)
-nbfdaDon´t put each argument in a function declaration
on a separate line (default)
-lp Line up continued lines at parentheses (default)
-psl Put the type of a procedure on the line before its name.
-bbo Prefer to break long lines before boolean operators.
Blank Lines
-nsob Do not swallow optional blank lines (default)
-bad Force a blank line after a declaration.
-bbb Force a blank line before a block comment.
-bap Force blank lines after procedure bodies.
Comments
-fca Reformat all comments except those starting in column 1
-fc1 Reformat comments starting in column 1
-sc Continuation lines in a comments start with a '*'
Statements
-npcs Do not put space after the function in function calls.
-nprs Do not put a space after every ´(´ and before every ´)´.
-ncs Do not put a space after cast operators.
-saf Put a space after each for.
-sai Put a space after each if.
-saw Put a space after each while.
-brs Put braces on struct declaration line.
-br Put braces on line with if, etc.
-ce Cuddle else and preceeding `}´.
-cdw Cuddle while of do {} while; and preceeding `}´.
Other
-l80 Line width of 80.
Attached is a small source file formatted with the above options.
Let the discussion begin. :-)
Of the above list of options, the ones I feel strongly about are lining
up continued lines at parentheses (-lp), the space-after-keyword group
(saf, -sai, -saw), and the cuddling-of-braces group (-br, -ce, -cdw). I
feel most strongly about this last group. The parts of an if/then/else
statement are clearly delineated by the indentation of the keywords vs.
the indentation of the code blocks. I believe it a complete waste to
additionally add vertical separation my making the else take up three
lines. One for a closing parenthesis, one for the word else, and one
for an opening parenthesis. Maybe that's just me.
What do the rest of the developers think?
I like it. It's basically KR, but with -bad -psl and some
comment-formatting.
I would recommend adding -ss, and I would have defaulted to -cli0,
which is also KR, but I don't feel strongly about it.
-chris
David
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: indent
I also recommend
-T ExampleType
for every 'typedef', so that you get:
example(int foo, char *bar, ExampleType *aligned_here)
and not
example(int foo, char *bar, ExampleType * aligned_here)
-- Peter
David Hampton wrote:
There's been some discussion on IRC about using the indent program to
reformat the sources into something consistent from file to file. I'd
like to propose the following options as a starting point for
discussion. I think some of these options will be agreed upon by all,
and I'm sure others will be contentious. :-)
Indentation
-nutNo tabs. Indentation is done with spaces.
-i4 Add four spaces for each indent level
-ci4Continuation lines are indented by four spaces
-cli4 Case labels are indented by four spaces
-ppi4 Nested pre-processor defines are indented by four spaces
-nbcDo not force newlines after commas in declarations (default)
-nbfda Don´t put each argument in a function declaration
on a separate line (default)
-lp Line up continued lines at parentheses (default)
-pslPut the type of a procedure on the line before its name.
-bboPrefer to break long lines before boolean operators.
Blank Lines
-nsob Do not swallow optional blank lines (default)
-badForce a blank line after a declaration.
-bbbForce a blank line before a block comment.
-bapForce blank lines after procedure bodies.
Comments
-fcaReformat all comments except those starting in column 1
-fc1Reformat comments starting in column 1
-sc Continuation lines in a comments start with a '*'
Statements
-npcs Do not put space after the function in function calls.
-nprs Do not put a space after every ´(´ and before every ´)´.
-ncsDo not put a space after cast operators.
-safPut a space after each for.
-saiPut a space after each if.
-sawPut a space after each while.
-brsPut braces on struct declaration line.
-br Put braces on line with if, etc.
-ce Cuddle else and preceeding `}´.
-cdwCuddle while of do {} while; and preceeding `}´.
Other
-l80Line width of 80.
Attached is a small source file formatted with the above options.
Let the discussion begin. :-)
Of the above list of options, the ones I feel strongly about are lining
up continued lines at parentheses (-lp), the space-after-keyword group
(saf, -sai, -saw), and the cuddling-of-braces group (-br, -ce, -cdw). I
feel most strongly about this last group. The parts of an if/then/else
statement are clearly delineated by the indentation of the keywords vs.
the indentation of the code blocks. I believe it a complete waste to
additionally add vertical separation my making the else take up three
lines. One for a closing parenthesis, one for the word else, and one
for an opening parenthesis. Maybe that's just me.
What do the rest of the developers think?
David
#ifdef A
#ifdef B
#define C
#else
#define D
#endif
#else
#define E
#endif
/***
* *
***/
struct foo {
int i, j;
char *s;
};
char *a;
char *b;
/* kssf */
char *g;
/*
* Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod
* tempor incididunt ut labore et dolore magna aliqua.
. */
static void
example(int foo, char *bar, ExampleType * aligned_here)
{
Foo *bar = { 1, foo };/* lorem ipsum */
for (int i = 0; i 10; i++) {
if (is_is_a_reasonable_value(i)
(i 10 || i 11)) {
// ...
} else {
break;
}
}
this_is_a_long_function_name(and_this, function, has_a_very, large,
number_of, arguments);
switch (foobar) {
case 0:
z = is_is_a_reasonable_value(i);
break;
default:
z = !is_is_a_reasonable_value(i);
break;
}
while (TRUE) {
// ...
}
do {
// ...
} while (TRUE);
}
static void
another_example(int and_this, char *function, ExampleType * has_a_very,
char *large, double number_of, int arguments)
{
}
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
