Wrong formatting a line comment within type declaration in class
Closed this issue · 7 comments
Hi!
I'm using the latested Abap-Cleaner and just let it format a global class. I noticed that the cleaner did format a line comment wrong. Instead of keeping the comment in the current line, at the beginning, the line has been moved to the end of the previous line.
I'm using the default profile and the code preview gives the same result, btw.
This is the code block, pls. note the line 20 *,billing_to_partner that is commented out.
types:
BEGIN OF t_data_ext
,operation TYPE zcl_cs_operations=>t_operation-vornr
,workhour TYPE zzconfirmworkhour
,unit_workhour TYPE zzconfirmworkhrunit
,travel TYPE zzconfirmtravel
,unit_travel TYPE zzconfirmtravelunit
,replace_costs TYPE zzconfirmreplcosts
,unit_replace_costs TYPE zzconfirmreplcostsunit
,rebate TYPE zzconfirmrebate
,unit_rebate TYPE zzconfirmrebateunit
,other TYPE zzconfirmother
,unit_other TYPE zzconfirmotherunit
,material TYPE zzconfirmmaterial
,unit_material TYPE zzconfirmaterialunit
,goodwill TYPE zzconfirmgoodwill
,billing TYPE zzconfirmbilling
,billing_to TYPE zzbillingdecision
*,billing_to_partner TYPE ihpa-parnr
,warranty TYPE zzconfirmwarranty
,revisited TYPE zzconfirmrevisited
,plumber_informed TYPE zzconfirmplumbinfo
,plumber_onsite TYPE zzconfirmplumbonsite
,task_for_office TYPE zzconfirmofficetask
,customer_notonsite TYPE zzconfirmcustomernotonsite
,confirmation_info TYPE zcl_cs_longtext=>tt_lines
,start_date TYPE zzconfirmsdate
,end_date TYPE zzconfirmedate
,service_render_date TYPE zcl_cs_order_confirmation_fsm=>t_serv_rend_date
"Weitere Meldungsdaten
,symptoms TYPE tt_symptoms "Schadensbilder
,parts TYPE tt_parts "Objektteile
,item_quantities TYPE tt_item_quantities "Positionsmengen
,causes TYPE tt_causes "Ursachen
,spareparts TYPE tt_spareparts "Ersatzteile
,in_operation_date TYPE iflot-datab "Inbetriebnahmedatum
,closing_partner TYPE zcl_cs_order_confirmation=>t_closing_partner "Rückmeldepartner
,service_order TYPE caufvd-aufnr
,dialog_answers type zcl_cs_order_confirmation_fsm=>t_dialog_answers
,END OF t_data_ext .
After running the code cleaner, starting with Ctrl+4, the result is like:
TYPES:
BEGIN OF t_data_ext,
operation TYPE zcl_cs_operations=>t_operation-vornr,
workhour TYPE zzconfirmworkhour,
unit_workhour TYPE zzconfirmworkhrunit,
travel TYPE zzconfirmtravel,
unit_travel TYPE zzconfirmtravelunit,
replace_costs TYPE zzconfirmreplcosts,
unit_replace_costs TYPE zzconfirmreplcostsunit,
rebate TYPE zzconfirmrebate,
unit_rebate TYPE zzconfirmrebateunit,
other TYPE zzconfirmother,
unit_other TYPE zzconfirmotherunit,
material TYPE zzconfirmmaterial,
unit_material TYPE zzconfirmaterialunit,
goodwill TYPE zzconfirmgoodwill,
billing TYPE zzconfirmbilling,
billing_to TYPE zzbillingdecision *,billing_to_partner TYPE ihpa-parnr
,
warranty TYPE zzconfirmwarranty,
revisited TYPE zzconfirmrevisited,
plumber_informed TYPE zzconfirmplumbinfo,
plumber_onsite TYPE zzconfirmplumbonsite,
task_for_office TYPE zzconfirmofficetask,
customer_notonsite TYPE zzconfirmcustomernotonsite,
confirmation_info TYPE zcl_cs_longtext=>tt_lines,
start_date TYPE zzconfirmsdate,
end_date TYPE zzconfirmedate,
service_render_date TYPE zcl_cs_order_confirmation_fsm=>t_serv_rend_date " Weitere Meldungsdaten
,
symptoms TYPE tt_symptoms, " Schadensbilder
parts TYPE tt_parts, " Objektteile
item_quantities TYPE tt_item_quantities, " Positionsmengen
causes TYPE tt_causes, " Ursachen
spareparts TYPE tt_spareparts, " Ersatzteile
in_operation_date TYPE iflot-datab, " Inbetriebnahmedatum
closing_partner TYPE zcl_cs_order_confirmation=>t_closing_partner, " Rückmeldepartner
service_order TYPE caufvd-aufnr,
dialog_answers TYPE zcl_cs_order_confirmation_fsm=>t_dialog_answers,
END OF t_data_ext.
Did you spot the wrong part of the code:
billing_to TYPE zzbillingdecision *,billing_to_partner TYPE ihpa-parnr
Is this sthg. I could prevent by adjusting the profile or is it more or less a bug?
Michael
Hi Michael,
thanks a lot for reporting this – that's clearly a bug! (It's certainly also a very unusual way of placing commas… but that's not an excuse :-)
Kind regards,
Jörg-Michael
Yes, surely is unusual but should not confuse the clearner ;-)
Thanks for reading and probably fixing it!
Hi Michael,
this should be fixed with the next release: For one thing, the rule "Remove space before commas and period" will have a new option "Move comma or period across comment lines" (default on), while will also move the last comma in this example:
What can't be done, of course, is to handle the comma at the beginning of a commented-out code line, so if that's ever commented in again, some manual adjustment will be necessary (which seems to me like a fair punishment for such an awful coding style):
Secondly, even if someone deactivates the new option, the "Align declarations" rule will now keep comment lines (instead of erroneously moving them to the end of the previous line):
As you can see, the commas end up in a separate lines in this case, but at least, no syntax error is introduced; and if "Remove space before commas and period" is active, you won't get this anyway.
Kind regards,
Jörg-Michael
P.S.: So, altogether, you will get this for your example:
TYPES:
BEGIN OF t_data_ext,
operation TYPE zcl_cs_operations=>t_operation-vornr,
workhour TYPE zzconfirmworkhour,
unit_workhour TYPE zzconfirmworkhrunit,
travel TYPE zzconfirmtravel,
unit_travel TYPE zzconfirmtravelunit,
replace_costs TYPE zzconfirmreplcosts,
unit_replace_costs TYPE zzconfirmreplcostsunit,
rebate TYPE zzconfirmrebate,
unit_rebate TYPE zzconfirmrebateunit,
other TYPE zzconfirmother,
unit_other TYPE zzconfirmotherunit,
material TYPE zzconfirmmaterial,
unit_material TYPE zzconfirmaterialunit,
goodwill TYPE zzconfirmgoodwill,
billing TYPE zzconfirmbilling,
billing_to TYPE zzbillingdecision,
*,billing_to_partner TYPE ihpa-parnr
warranty TYPE zzconfirmwarranty,
revisited TYPE zzconfirmrevisited,
plumber_informed TYPE zzconfirmplumbinfo,
plumber_onsite TYPE zzconfirmplumbonsite,
task_for_office TYPE zzconfirmofficetask,
customer_notonsite TYPE zzconfirmcustomernotonsite,
confirmation_info TYPE zcl_cs_longtext=>tt_lines,
start_date TYPE zzconfirmsdate,
end_date TYPE zzconfirmedate,
service_render_date TYPE zcl_cs_order_confirmation_fsm=>t_serv_rend_date,
" Weitere Meldungsdaten
symptoms TYPE tt_symptoms, " Schadensbilder
parts TYPE tt_parts, " Objektteile
item_quantities TYPE tt_item_quantities, " Positionsmengen
causes TYPE tt_causes, " Ursachen
spareparts TYPE tt_spareparts, " Ersatzteile
in_operation_date TYPE iflot-datab, " Inbetriebnahmedatum
closing_partner TYPE zcl_cs_order_confirmation=>t_closing_partner, " Rückmeldepartner
service_order TYPE caufvd-aufnr,
dialog_answers TYPE zcl_cs_order_confirmation_fsm=>t_dialog_answers,
END OF t_data_ext.That fits perfectly well - good job!
Regarding the comma after the comment character, this is OK, too, for me and I guess for others, too. One could de-comment those lines, call the cleaner and comment it again afterwards. IMO, this does not make sense anyway.
Hi Michael,
thanks for your feedback – this should now be fixed with version 1.18.0, which was just released!
Kind regards,
Jörg-Michael
Updated -> Works!
Perfect, thanks!