Re: First C program

Just a comment on coding style:
I understand there are some nasty traps that an RPG coder can fall into, but you should avoid awkward constructs that mimic or build on RPG style of coding. One reason for using C could be access to skilled personnel, C skills should be more easily accessible than RPG skills these days; you don't want a situation where a generally good C coder will have a hard time understanding your programs.
Regardless, maybe you will not maintain this program for the rest of your life... ;-)


/Joakim


Joakim Lindbom
Principal | Certified Enterprise Architect

Capgemini Sweden / Application Consulting / Sales Enablement

Tel: +46 8 5368 3934 / Skype: joakim.lindbom
www.capgemini.com

People matter, results count.
________________________________________
Från: [email protected] [[email protected]] för Frank Kolmann [[email protected]]
Skickat: den 3 april 2014 12:39
Till: c400-l
Ämne: [C400-L] First C program

Hi Jevgeni



Thank you.  You make good points.

That is a good way of trapping the == issue.

I will follow Barbaras advice in the coding of the if.



I like the way you use the #define for the type defs.

It does make the code clearer, I will use that sytle.



Frank





>*Subject: Re: First C program

>*From: Jevgeni Astanovski <Jevgeni.Astanovski@xxxxxxxxxxxxx>

>*Date: Wed, 2 Apr 2014 07:54:34 +0000

>Yes. Barbara mentioned the define and I haven't...

>Definitely there are lots of this sort of advises to avoid =/== possible
mistake.

>I've never saw the one you referred.

> However some use another technique:

>Instead of writing

>if ((pf = _Ropen(PFILENAME, "rr")) == NULL)

>they write

>if (NULL == (pf = _Ropen(PFILENAME, "rr")))

>In this case if you make a mistake and write

>if (NULL = (pf = _Ropen(PFILENAME, "rr")))

>you will immediately get a syntax error.

>

....

>

>On the second issue - this is purely a question of how readable is your
program.

> My personal practice is to use "explicit" way of defining types. For
example:

>

>#pragma mapinc("dspf", "*LIBL/Y80ALD(ADDCHRG)", "both", "_P", "Y80", "Y80")

> #include "dspf"

> #define INPUT_T Y80_ADDCHRG_i_t

> #define OUTPUT_T Y80_ADDCHRG_o_t

>
>in this case it is (more) clear where these types are derived from....
--
This is the Bare Metal Programming IBM i (AS/400 and iSeries) (C400-L) mailing list
To post a message email: [email protected]
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/c400-l
or email: [email protected]
Before posting, please take a moment to review the archives
at http://archive.midrange.com/c400-l.

________________________________

Capgemini is a trading name used by the Capgemini Group of companies which includes Capgemini Sverige AB, a company registered in Sweden (number 556092-3053) whose registered office is at Gustavslundsvägen 131 Box 825 – S-161 24 Bromma.
This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message.
-- 
This is the Bare Metal Programming IBM i (AS/400 and iSeries) (C400-L) mailing list
To post a message email: [email protected]
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/c400-l
or email: [email protected]
Before posting, please take a moment to review the archives
at http://archive.midrange.com/c400-l.