[pb46 spoilers] Hitru lurks again

[naufragar]

Everytime there's a whitespace the compiler knows that this is a new code element. By the way this also the same reason

There's another topic about writing style, but I will leave it for next time.

Same reason what?!?!  

[Charriu]

Sorry for that, naufragar. That sentence should have been deleted.

Digging into the code

Fractal (Actual name: CvFractal) 417 lines

For once this is actually what you expect. This class helps in creating Fractal maps, you know the map type Fractal. Some of the calculations during map creation were most likely a bit performance intensive, so the developers outsourced this code to the C++ code. The reason for that is that C++ is able to micromanage those performance issues better then a high level programming language such as python.

You remember back at the city of DiploParameters that there is another reason for the "crazy" writing styles in programming languages. These styles are called Case Styles and there are quite a few:

• camelCase
  
• PascalCase
  
• snake_case
  
• kebab-case
  
• lowercase
  
• UPPERCASE
  
• Capitalizedcase
  

Depending on you programming language there are more or less restrictions of which writing style you use, but normally you are not limited to one style. The main reason - and mostly the only one - for using these styles is to quickly differentiate between, which names belong to classes, methods or variables. Take this snippet of code from the CvFractal class:

Code:

int CvFractal::getHeight(int iX, int iY)
{
    int iErrX;
    int iErrY;
    int iSum;
    int iHeight;
    int iLowX;
    int iLowY;

    FAssertMsg(0 <= iX && iX < m_iXs, "iX out of range");
    FAssertMsg(0 <= iY && iY < m_iYs, "iY out of range");
    iLowX = ((m_iXInc * iX) / FLOAT_PRECISION);
...

Because I know the conventions of the writing style, it is very easy for me to immediately notice what is what. For example:

• I immediately know that CvFractal and FAssertMsg are classes because all classes are written in PascalCase
  
• I know that iHeight and iLowX are local variables (meaning belonging only to this method). I know that because they are written in camelCase
  
• I know that m_iXs and m_iXInc are member variable of the CvFractal class (meaning belonging only to this class). That I know because they are written in camelCase and begin with an m_
  
• I know that FLOAT_PRECISION is a constant variable, because it's written in snake_case and UPPERCASE
  
• Lastly I know that getHeight is a method, because it is written in camelCase followed by braces.
  

Using different writing styles therefore increases the readability of code.

[AutomatedTeller]

Sorry for that, naufragar. That sentence should have been deleted.

Digging into the code

Fractal (Actual name: CvFractal) 417 lines

For once this is actually what you expect. This class helps in creating Fractal maps, you know the map type Fractal. Some of the calculations during map creation were most likely a bit performance intensive, so the developers outsourced this code to the C++ code. The reason for that is that C++ is able to micromanage those performance issues better then a high level programming language such as python.

You remember back at the city of DiploParameters that there is another reason for the "crazy" writing styles in programming languages. These styles are called Case Styles and there are quite a few:

• camelCase
  
• PascalCase
  
• snake_case
  
• kebab-case
  
• lowercase
  
• UPPERCASE
  
• Capitalizedcase
  

Depending on you programming language there are more or less restrictions of which writing style you use, but normally you are not limited to one style. The main reason - and mostly the only one - for using these styles is to quickly differentiate between, which names belong to classes, methods or variables. Take this snippet of code from the CvFractal class:

Code:

int CvFractal::getHeight(int iX, int iY)
{
    int iErrX;
    int iErrY;
    int iSum;
    int iHeight;
    int iLowX;
    int iLowY;

    FAssertMsg(0 <= iX && iX < m_iXs, "iX out of range");
    FAssertMsg(0 <= iY && iY < m_iYs, "iY out of range");
    iLowX = ((m_iXInc * iX) / FLOAT_PRECISION);
...

Because I know the conventions of the writing style, it is very easy for me to immediately notice what is what. For example:

• I immediately know that CvFractal and FAssertMsg are classes because all classes are written in PascalCase
  
• I know that iHeight and iLowX are local variables (meaning belonging only to this method). I know that because they are written in camelCase
  
• I know that m_iXs and m_iXInc are member variable of the CvFractal class (meaning belonging only to this class). That I know because they are written in camelCase and begin with an m_
  
• I know that FLOAT_PRECISION is a constant variable, because it's written in snake_case and UPPERCASE
  
• Lastly I know that getHeight is a method, because it is written in camelCase followed by braces.
  

Using different writing styles therefore increases the readability of code.

I've been doing software development since 1990 and this is the first I've heard of snake_case or kebab-case.   I love learning new stuff ; Your explanations are pretty good, btw.  I approve the "RB Guide to Software Engineering"

[Charriu]

Thanks, I really appreciate that, especially if it comes from somebody, who has more experience in software development. I'm only working in the field since 2010.

EDIT: Oh and to clarify for everybody else:

I love learning new stuff

Is one of the foundational principles in software development. You are constantly learning new stuff in software development and this won't stop till your retirement.

[shallow_thought]

I've been doing software development since 1990 and this is the first I've heard of snake_case or kebab-case.   I love learning new stuff ; Your explanations are pretty good, btw.  I approve the "RB Guide to Software Engineering"

Thanks, I really appreciate that, especially if it comes from somebody, who has more experience in software development. I'm only working in the field since 2010.

I love learning new stuff

Is one of the foundational principles in software development. You are constantly learning new stuff in software development and this won't stop till your retirement.

Wow, 1990. I thought I was on ... um ... experienced side for this site (IRL) and I've only been doing software dev since 1997 (well, professionally). But absolutely, learning new stuff is one of the nice things about the job.

And yeah, I haven't had anything much to add to Charriu's posts yet, and certainly nothing to disagree with.

[Old Harry]

I'm hoping to use Charriu's programming 101 to get a job at some point...

Turn 62

Things are getting a bit hairy now. EventReporter survives and should get reinforcements before any other barbarians can hit it. DiploParameters faces a 92HP Combat 1 warrior though (did it kill Pindicator's scout?) The odds should be 95% in our favour, but that's still 1/20 that we lose the city. The chariot is one turn late to do anything about that, but just in time to stop the second (!) warrior if the first doesn't ruin our game. We debated leaving the worker out as a decoy, but decided the risk was better than definitely losing a quarter of our workforce.

If DiploParameters survives then we've produced the exact optimal number of units to sustain our expansion. If it falls then we're idiots who took too many chances...


Demos and power. Still number one, just.

[Old Harry]

Pbspy is telling me that we're idiots. I can't face logging in to see... The worst bit is the settler that was due in a couple of turns almost makes the city worth two cities.


At least the score decrease was covered by a pop increase so our rivals won't realise.

[Old Harry]

Turn 63

Well it could have been worse, the barb won at 3%, but our chariot captures back flawlessly and should have >99% defending against the next warrior. To add compliment to injury the terrace survived both captures so we're really only down one Quechua, one pop and 50 hammers in a settler (essentially that's our eighth city, so the snowball is slowed but not melted). It doesn't feel like a reason to celebrate, but we're not as badly damaged as we'd assumed.


Demos and power. Anyone else who is tracking city founding will assume with that capture that we're on 7 cities now. That's pretty funny given how we're actually feeling.

[Charriu]

Turn 63

Anyone else who is tracking city founding will assume with that capture that we're on 7 cities now. That's pretty funny given how we're actually feeling.

I wonder if I can keep up that illusion by writing just after you, like I did after every other city founding. 

[Old Harry]

Turn 64

Our chariot won flawlessly (it gets the +25% defence against barbs, which helped) and Pindicator got the event where his unit got healed. I'm pretty sure Pindi settled on the highlighted tile, so we should get a trade connection as soon as we settle our peninsula city. Whether we offer open borders is a tricky question. We'll have our overseas city already, so it'll only give him the economic benefit, but it allows us to scout him and make sure he's got no designs on attacking us.


Demos and power. We got graphs on Elkad so all of those are included.