Update functions lessons in pyramid project

[jeremylt]

Describe the Issue

This is a common sticking point for learners. It seems that creating and calling a function with 2 arguments is a substantial step up in difficulty from calling a function with 1 argument. We may need to reword this lesson to introduce the idea that functions can have 2 arguments.

Affected Page

https://www.freecodecamp.org/learn/javascript-algorithms-and-data-structures-v8/learn-introductory-javascript-by-building-a-pyramid-generator/step-55

Your code

Varies

Expected behavior

Clearer introduction of 2+ arguments

Screenshots

No response

System

All

Additional context

No response

[plamoni]

Step 47 makes a reference to multiple parameters:

A function may have as many, or as few, parameters as you'd like.

It might be reasonable to update this language to include information on the syntax of multiple parameters. E.g.

A function may have as many, or as few, parameters as you'd like. Multiple parameters are separated by commas, like with elements within an array.

Arrays with multiple, comma-separated elements are introduced back in Step 19.

In general, we don't present the same information multiple times. So putting it in step 47 and expecting Campers to retain that info or go back and find it if they get stuck on step 55 seems reasonable. But it might not hurt to reiterate the comma-separation syntax on step 55.

[jeremylt]

Yeah, I think Step 47 and/or 55 referencing comma separated arguments, with at least one example, would be good.

[plamoni]

For the sake of getting something in, let's move forward with the update to Step 47.

Whoever picks this up may use my proposed language or propose their own. If they want to also propose clarifying language in step 55, I'd be open to seeing that and discussing it in the review process.

[jeremylt]

Where should an example of a function with 2 arguments go? Replacing the example in 47? A second example in 47? In Step 55? I'm not sure what option I like.

[plamoni]

Where should an example of a function with 2 arguments go? Replacing the example in 47? A second example in 47? In Step 55? I'm not sure what option I like.

I honestly think we can just mention the syntax (without a code example of multiple parameters) in step 47 and not make a change to step 55 or to demo code. Just pointing out that multiple parameters are comma-separated should be sufficient without the need to show an example and should encourage Campers to do a little experimentation if needed.

Though, as I noted above, I'd be open to seeing a proposed change to step 55 as part of a PR to resolve this Issue.

[jeremylt]

I suspect more will be needed but that's a fair starting place.

[Aditi571]

I have introduced the idea of 2 arguments in step 47 and in step 55 ,i made a reference to step 47 in case the user forgets about the example in step 47.

[jeremylt]

I don't think we can reference specific step numbers in the instruction text, as the Step numbers change sometimes

[Aditi571]

Then we can remove the reference from step 55 as the idea of 2 parameters with example is already given in step 47.

[Aditi571]

@jeremylt I have resolved the comments

[hbar1st]

hi guys, I just found out through the original camper who noticed this that step 64 teaches how to write multiple parameters!! Looks like the steps are out of order? https://www.freecodecamp.org/learn/javascript-algorithms-and-data-structures-v8/learn-introductory-javascript-by-building-a-pyramid-generator/step-64

[plamoni]

I went and took a deeper look at what's going on here.

It turns out that Step 55 was added as part of a resolution to #54962.

The need for #54962 was to give campers a chance to review some earlier material rather than to introduce new material. So I don't think @jdwilkin4 meant to have this be new material.

I'm also not 100% convinced the intent was to put these steps into the pyramid project. From #54962:

We have heard from a few campers going through the gradebook app, that they weren't as comfortable with functions when starting the project and had to repeat certain sections of the pyramid project.

While reviewing aspects of previous projects is not a bad thing, we should build in more review steps for functions to make sure campers really understand how they work.

To me, the solution to avoiding having campers go back to the pyramid project is to give review material in the gradebook project. Though I could understand if the intent was to reiterate the material the camper had just been introduced to.

Either way, it seems clear the intent was for this material to be review and not new material. So I think our solution wasn't the right one. Rather than adjusting the language, we might want to adjust the step ordering (or even move the lesson over to the gradebook project).

If @jdwilkin4 spots this, maybe she can provide some insight into her intent regarding #54962 and how she might want to move things given the problem identified by this issue.

Going to move this back to discussion until we can get that figured out.

[jdwilkin4]

@plamoni

I'm also not 100% convinced the intent was to put these steps into the pyramid project

It looks like there was a misunderstanding for what I wrote in that issue.

When the gradebook app was first introduced, campers were going back to the pyramid project because they felt like they never understand functions at all and needed more practice before the gradebook app.

So, that was the purpose for step 55. Give them more repetition and review what they have learned. Not introduce new concepts.

That way they will feel more comfortable doing the gradebook app. If they still want to go back and review parts of the pyramid project, that isn't the end of the world and they are of course free to do that. But if they do back to the pyramid project to review, it should be as a quick refresher. Not as a "I never understand functions and learning it for the first time" That is the issue we are trying to solve with review steps right after they just learned a concepts so it sticks better.

or even move the lesson over to the gradebook project.

The whole purpose of adding the review projects in the first place was to give campers the opportunity to build functions and solve problems on their own with information they already learned. Not introduce new information.

So all new information should be kept inside the learn projects. not review projects.

I think a cleaner solution would be to restructure the functions section completely

Here are my proposed steps:

• step 47 - teach function declarations. Example code should not include parameters because that will be taught later. Have campers declare a function called addThreeAndSeven
• step 48 - teach function calls. Have them log the function call to the console to see the result

  
  function addThreeAndSeven() {

}

console.log(addThreeAndSeven())

- step 49 - teach return values and talk about why it is currently returning undefined. Have them return 3+7
- step 50 - have campers create another function called `addTwoAndFour` that returns the sum. Also, have them log the function call.
```js
function addTwoAndFour(){
return 2+4
}

console.log(addTwoAndFour())

• step 51 - talk about how the current code is repetitive and code be refactored. have them remove the code they have written so far
• step 52 - teach parameters. Show example with multiple parameters. Have them declare a addTwoNumbers function with two parameters

  
  function addTwoNumbers(num1,num2){

}

- step 53 - have them return the sum of num1 and num2
- step 54 - teach arguments. Have them call the function and pass in two numbers for arguments. Then they will log the result
```js
function addTwoNumbers(num1,num2){
 return num1 + num2
}

console.log(addTwoNumbers(2,4))

• step 55 - have campers add two more function calls to further emphasize the reusability of functions with different arguments

  
  function addTwoNumbers(num1,num2){
  return num1 + num2
  }

console.log(addTwoNumbers(2,4)) console.log(addTwoNumbers(13,9)) console.log(addTwoNumbers(5,50))

- step 56 - have a review step where they will create a new function called `greetUser` with a parameter of `user`. Then they will return greeting of hello user using string concatenation. Then have them log the function call with a string argument
```js
function greetUser(user){
  return "Hello " + user
}

console.log(greetUser("Jessica"))

• step 57 - have them remove all function code including the console statements
• step 58 - have them create a function called padRow with a parameter called name. The function should return name. Also, just provide them with the call variable and console statement here

  const call = padRow("CamperChan");
  console.log(call);

• Step 59 and onwards. Resume with rest of steps starting with this one.

[xTektonicx]

What about step 64? Your proposed change to 52 would make 64 super redundant. Which isn’t bad I guess but something to look at! :) overall I love what I’m seeing! @jdwilkin4

[hbar1st]

i opened a feature request earlier to ask to update the course to explain hardcoding (here: https://github.com/freeCodeCamp/freeCodeCamp/issues/55590) Would it be possible to explain hardcoding somewhere in this new sequence? For eg. before teaching them to add 2 numbers with the parameters, in step 53/54 (not sure which based on above) they could purposely be told to ignore the parameters and just return again 2+4 and we can explain that this is called hardcoding? After that ask them to use the parameters? Maybe also include an explanation of when hardcoding is useful for debugging though this sample function may be too simple?

[jdwilkin4]

What about step 64? Your proposed change to 52 would make 64 super redundant.

For current step 64, we just need to remove the example and the last sentence

Multiple parameters are separated by a comma:

It is a simple fix, that can be solved in a separate issue for first timers only

[jdwilkin4]

they could purposely be told to ignore the parameters and just return again 2+4 and we can explain that this is called hardcoding? After that ask them to use the parameters?

I don't think we need to have another step to return 2+4 again. In the new step 51, we will talk about how the current code is too repetitive. So that would be the perfect place to talk about hardcoding.

Maybe also include an explanation of when hardcoding is useful for debugging though this sample function may be too simple?

We should avoid introducing to many new concepts all at once. Campers don't do well with that. These set of steps should just focus on the basics of working with functions (function declarations, return statements, parameters, arguments, etc)

Something like that should be introduced in the debugging project here https://www.freecodecamp.org/learn/javascript-algorithms-and-data-structures-v8/learn-basic-debugging-by-building-a-random-background-color-changer/step-1

[xTektonicx]

Just wanted to say thank you everyone for accepting my feedback. I’m a newbie here. 🖤

[naomi-lgbt]

Let's go ahead and move forward with this. We can always iterate further in additional discussions if needed.

A PR which resolves this issue should implement Jessica's proposed fix: https://github.com/freeCodeCamp/freeCodeCamp/issues/55573#issuecomment-2241764017