Making code smaller

Greetings. I am somewhat new to the Arduino world so i am hoping this will be an easy one. I am going to be making custom LED flash patterns and it will use up quite a bit of memory. My question is this, Can I substitute the digital writes in the code like this:

int ledPin = 13;
void setup()
{
  pinMode(ledPin, OUTPUT);
}

void loop()
{
  digitalWrite(ledPin, HIGH);
  delay(1000);                  
  digitalWrite(ledPin, LOW);    
  delay(1000);                  
}

to be smaller, for example:

int ledPin = 13;
ledoff = digitalWrite(ledPin, LOW);
ledon = digitalWrite(ledPin, HIGH);
void setup()
{
  pinMode(ledPin, OUTPUT);
}

void loop()
{
  ledon;
  delay(1000);                  
  ledoff;    
  delay(1000);                  
}

This way there would be a little more data specifying values, but the actual code to turn LEDs on and off would be smaller so I can program more complex flash patterns.

Is something like this possible?

Can I substitute the digital writes in the code like this:

No.

but the actual code to turn LEDs on and off would be smaller so I can program more complex flash patterns.

No. If you mean to make functions to turn the LEDs on/off, there will actually be more code.

The answer to the question you asked is "no", but you may be able to display more complex patterns by storing those patterns more compactly, and writing "smarter" code to present those patterns.

Sounds like functions is what I want... Thank you much! Not sure why I did not think of that.

Can do it this way:
Use pinModes to set the pin directions as you have now.

Then use AND to make an output low:
PORTD = PIND & B01111111; // make bit 7 low, rest are unchanged

Not a whole shorter writing your code, but way less code to actually execute because all the smarts behind digitalWrite are skipped.
OR to make an output high:
PORTD = PIND | B10000000; // make b it 7 high, rest are unchanged

I am going to be making custom LED flash patterns

How complex are these going to be? If you store the details of your patterns in arrays in progmem, the driver code to execute it could be very small indeed.

code should not be shorter, it should be more readable to be maintainable ...

this is almost as short as I can make your code, not very readable ...

int s;void setup(){pinMode(13,1);}void loop(){digitalWrite(13,s=!s);delay(1e3);}

/*
 * Original:
 *     Binary sketch size: 1026 bytes (of a 32256 byte maximum)
 * Modified:
 *     Binary sketch size: 1012 bytes (of a 32256 byte maximum)
 */

// Save 14 bytes by ...

// ...adding const (saves 8 bytes) ...
const int   ledPin = 13;

// ... and delcaring 's' as type required by digitalWrite ...
// ...  (saves 2 bytes)
uint8_t     s;

void setup()
{
    pinMode(ledPin, 1);
}

void loop()
{
    // ... and code refactor save additional 4 bytes ...
    digitalWrite(ledPin, s = !s);
    delay(1000UL);
}

"Complex patterns" doesn't tell me much other than that you either have a lot of LEDs to control, that you want to control them in complex rhythms, that you want to vary the colors and/or intensity of your LEDs, or some combination of the above...

Would you please define what you mean by "complex patterns" , how many LEDs, and what kind(s) of control you want to exercise?

If you want to flash LED patterns you might want to have a look at my Blinkenlight pages: http://blog.blinkenlight.net. For storage of LED patterns in flash memory you might definitely want to have a look at my persistence of vision experiments. You find the first one here: Persistence of Vision | Blinkenlight.

I recommend to not just look at this experiment. I have lots of variations that might or might not better suit your needs.

Sounds like functions is what I want...

you can certainly write an "output function", so whenever you want to send-out (or change) a pattern, you pass the pattern to the function and call the function instead of duplicating digitalWrite every time you want to turn on/off an LED.

Besides functions, loops are another way to make your code "smaller". If you are doing something over-and-over, write a loop, rather than repeating the code over-and-over. And, it doesn't have to do exactly the same thing every time throught the loop. Variables can change, and you can have if-statements to change what the loop is doing. As a simple example, the 1st time through the loop, you could write a "0" to pin one. The next time through the loop, you could write a "1" to pin 4. ...And, if it's going through that same loop and more than 1000mS have passed, it can toggle the state of pin 13, etc., etc...

If there is some "logic", or "order", or "repetition" to these patterns, your code may be able to "generate" the patterns when needed, and you won't have to "store' the ones you are not using at the moment. I'm sure your project is different from mine, but I just finished a "blink-sequence to the music" project, and I don't store any patterns. Sometimes I'll write zero's or one's to get a "starting point" and other times I'll generate and "shift-in" a starting-pattern. Other times, it's random, or the pattern is generated depending on the loudness or beat. At most, I sometimes need to "save" a few bits that have shifted/sequenced-off the end of the display, so I can sequence them back in...

BTW - My project took-up about 9K of the 32K available. I'm only using 7 "channels" (7 output pins) because I have, eight strings of 7-lamps each that I need to control. But, there are 10 different "modes" and variations of each mode, for hundreds of overall variations. For example, all of the modes can be inverted or reversed... One of the modes is a VU meter effect. It can go left-to-right or right-to-left, and/or it can be inverted (so that louder-sound turns-off the lamps, instead of turning them on). The revese/invert options is a feature of my "output function", so with a few additional lines of code I have 4 times as many variations of all the patterns/modes. A few of the modes can use random patterns, so with 7 lamps I get 127 variations of those modes... I'm just saying that it's possble to get lots of patterns without storing them in memory.