When to use int, const int, const byte and Define

• If I write proper C++ classes - and go through the effort to make good architectured designs - I use const and enumerators. In those cases, I try to use the new features that the language offers.

class m25 {
public:
  m25(spi_inst_t * spi, uint sclk, uint mosi, uint miso, uint ncs, uint nhold, uint nwrite) : 
    spi(spi), sclk(sclk), mosi(mosi), miso(miso), ncs(ncs), nhold(nhold), nwrite(nwrite) {}
  ~m25() {}
  void init();
  std::vector<uint8_t> rdid();
  std::vector<uint8_t> rdsr();
  void write(uint32_t address, std::vector<uint8_t> data);
  std::vector<uint8_t> read(uint32_t address, size_t length);
  void be();

  bool set_nhold(bool set);
  bool set_nwrite(bool set);
  void config_protect(bool srwd, bool bp2, bool bp1, bool bp0);

private:
  enum commands : uint8_t { 
    WREN  = 0x06,
    RDID = 0x9F,
    RDSR = 0x05,
    WRSR = 0x01,
    READ = 0x03,
    PP   = 0x02,
    BE   = 0xC7 };
  spi_inst_t * spi;

In the example, in some locations I used uint instead of uintxx_t, like baldengineer suggests. I am also a fan of the uintxx_t types. But this is a wrapper around the RP2400 SDK, and they use uint. 
I try to adapt where I think it makes sense.

• When writing C, and prototyping, I use defines. 
• When I modify existing code, I usually stick to what the previous pundit used.

Jan, what do functions rdid() and rdsr() do?  Ditto set_nhold() and set_nwrite()?  I don't mean, the code, but what you would say in a function comment for them?  rdid() - is that reading an id for example?  What are the purposes of variables srwd, bp2?  

> what do functions rdid() and rdsr() do?

That's the name of a function you can do with flash.

> Ditto set_nhold() and set_nwrite()?

set the IC's NHOLD and NWRITE pins

> What are the purposes of variables srwd, bp2?  

I did that deliberately - match the manufacturer's names.

Yes, not picking on you .  

Why do C programmers always feel the need to abbreviate the heck out of variable and function names so that they aren't readily apparent?  Why not readId() {} or bool blockProtectBit2 etc... It feels like it's some undocumented standard somewhere or some C programmer brotherhood thing!  It's not like source code contributes to the final executable size.  Or is it that C programmers are unduly lazy and their poor fingers can't cope with having to type an extra few characters   Good job they didn't get into SmallTalk!

Not a C thing in this case. A choice:

I claim that I did not abbreviate anything . I used the language of the problem domain.

Andrew J said:

Why not readId() {} or bool blockProtectBit2 etc... It feels like it's some undocumented standard somewhere or some C programmer brotherhood thing!

RDID and BP2 are documented. If I use readID and blockProtectBit2, I'd have to document them. I think that it is an advantage of using domain specific lingo. OO advises to use the names of the problem domain.

If I were to write an abstract Memory class, I'd probably use a different type of name. But this one is close to a particular problem domain and I used their names.

I'd do the same with MISO, MOSI, ... . If I write a class that's a SPI wrapper, I'd call MISO, MOSI, nCS etc.
If I wrote an abstraction layer around serial chip protocols, I'd probably use read(), write(), select()

I wasn't referring to you specifically, I was being more philosophical, honest.  I bet the original "designers" of this thing were C programmers :)  They should have been calling them by their proper names for clarity.  

OO does say use domain language but what you have is not a problem domain, it's a specific instance within the problem domain.  My definite knowledge is to also call a Spade a "DiggingImplement spade = new DiggingImpement(BladeType typeOfBlade);" and not a " DigImpl spd = new DigImpl(Blade_t tp);"  But then I come from a SmallTalk background which would have been something like spade = new DiggingImplementWithBladeType: bladeType (SmallTalk is untyped because everything, including literal integers for example, are full blown Object or Object subclass instances).  

Anyway, as I say, I was being very generalist: you have to admit, there is a massive tendency in C programming to abbreviate function and variable names and I can't fathom the reason for it.  Except, yes, for MOSI, MISO I would use the same because the designers of that chose to abbreviate and they are absolutely well understood terms and used by everyone (unlike BP2, SRWD, WRDI etc.)

I wasn't referring to you specifically, I was being more philosophical, honest.  I bet the original "designers" of this thing were C programmers :)  They should have been calling them by their proper names for clarity.  

OO does say use domain language but what you have is not a problem domain, it's a specific instance within the problem domain.  My definite knowledge is to also call a Spade a "DiggingImplement spade = new DiggingImpement(BladeType typeOfBlade);" and not a " DigImpl spd = new DigImpl(Blade_t tp);"  But then I come from a SmallTalk background which would have been something like spade = new DiggingImplementWithBladeType: bladeType (SmallTalk is untyped because everything, including literal integers for example, are full blown Object or Object subclass instances).  

Anyway, as I say, I was being very generalist: you have to admit, there is a massive tendency in C programming to abbreviate function and variable names and I can't fathom the reason for it.  Except, yes, for MOSI, MISO I would use the same because the designers of that chose to abbreviate and they are absolutely well understood terms and used by everyone (unlike BP2, SRWD, WRDI etc.)