Lec005 G2 12-08-2026 Back-End Tanta

Main ideas & lessons (structured)

1) Admin / course logistics (brief)

• Materials & registration

  • Relevant lecture materials and registration-related information were sent/arranged.

• Scheduling guidance

  • Review time is built in (Sunday off) so students can go over lectures before the exam/quiz.
  • The next session/exam timing is described as unexpected/surprise.

• Attendance procedure

  • Students should use the link sent in the chat to register attendance within a short window.

• Exam continuation rule

  • Students scoring above a threshold (mentioned as 75%) continue to the next phase.
  • Those who do not score enough do not continue.

---

2) Core programming concept: Functions (with intuition + principles)

• Functions are reusable code blocks that perform a specific task.

• Analogy

  • Instead of rebuilding a kitchen every time you want tea/coffee, you build it once and reuse it—similar to defining code once and calling it many times.

• DRY principle (“Don’t repeat yourself”)

  • If you repeat lines of code 3+ times, move the repeated logic into a function and call it.

• Why functions are useful

  1. Code reuse (write once, use many times).
  2. Project organization (break large codebases into small functions with clear responsibilities).
  3. Easier maintenance (fix one function without touching the whole program; easier error localization).

---

3) Function “anatomy” (four main parts)

A function is described as consisting of four parts:

1. Header / label
2. Body
3. Return statement (optional, but part of the anatomy)
4. Function call / invocation (callback)

Function header details (how it’s formed conceptually)

• Starts with a reserved keyword (language-specific).
• Followed by the function name.
• Followed by parentheses (...).
• The parentheses hold information related to parameters (inputs).

Function body details

• Contains the code that executes when the function is called.

Return statement details

• A return statement means the function produces a value.
• Example idea: return 5 causes the function call to evaluate to 5 afterward.
• Return is not required in every function, but without it, the function call may not provide a usable value.

Function call / callback details

• Calling uses:
  • function name + parentheses, e.g., functionName(...)
• The code inside the body runs when the call happens.

---

Parameters, arguments, and inputs (terminology + behavior)

Key terminology differences

• Parameter (when defining a function)

  • A dummy/placeholder variable (often “mostly zero” / without a real value until called).
  • Lives in the parentheses in the function definition.

• Argument (when calling a function)

  • The actual value you pass in to the parameter at call time.

Speaker emphasis: parameters usually have no meaningful real value until the function is invoked; upon calling, the placeholder becomes associated with a concrete value (the argument).

How the “parameter → argument” mapping works

• If a function is defined with a parameter like h (placeholder),
• and you call it with h = 25 (argument),
• then the function uses 25 as the effective value internally.

Simple example explained (addition)

• A function is built for adding two numbers:
  • Defined with two parameters (e.g., a and b)
  • Uses arithmetic in the body
  • Uses return so the result becomes usable outside the function
• If return is removed, the caller would not receive the expected value as output.

---

Default parameters (example: greeting/message)

• A parameter can be given a default value.
• If the caller doesn’t supply that argument, the function uses the default.
• If the caller supplies it, it overrides the default.

Example concept:

• greeting(name, message="Hello")
  • If message not provided → returns "Hello <name>"
  • If message provided → returns "<message> <name>"

---

Function scope / variables scope

Rule of scope

“What happens inside the function stays inside the function.”

This refers to variable accessibility rules.

Two types of variables

1. Local variables

   • Created inside a function.
   • Exist only during function execution.
   • Not accessible outside the function (would cause errors if used outside).

2. Global variables

   • Defined outside functions (e.g., in main/global code).
   • Accessible throughout the program (any function can use them).

Name lookup order (how Python-like languages resolve variables)

1. Search inside the current function
2. If not found, check enclosing/surrounding scopes
3. Then check global scope
4. Then check built-in language names

---

Recursion (mentioned briefly)

• A recursive function is a function that calls itself.
• Mentioned as related to problems like factorial (no deep explanation in this clip).

---

Debugging (main concepts + methods + error types)

What debugging is

• Debugging = fixing errors in code.
• Framed as:
  • identify errors, then
  • debug removes/corrects them.

The “bug / debug / test” triangle

• Bug: a flaw/defect/error in code
• Debug: correcting the bug
• Test: verifying the program works and has no errors before delivery

Types of programming errors (three categories)

1. Syntax errors

   • Violate language writing rules.
   • Detected immediately by interpreter/compiler before execution.
   • Often easiest to identify because execution stops and points to the issue.

2. Runtime errors

   • Occur while the program is running.
   • Example: dividing by zero.
   • The program crashes/stops and raises exceptions.

3. Logical errors

   • The program runs and finishes normally, but the result is wrong.
   • Most dangerous because the computer may not warn you.
   • Requires careful result checking and code tracing.
   • Example exploitation: logic flaw in an e-commerce discount scheme.

Strategies/tools for debugging (listed methods)

• Print debugging

  • Add print statements at key points to verify execution paths and computed values.

• Breakpoints / stepping (IDE debugging)

  • Use tools like Visual Studio Code or PyCharm.
  • Step through execution line-by-line (e.g., “step over”).
  • Observe how variables change live.

• Rubber duck method (personal/professional technique)

  • Explain the code line-by-line as if teaching it (often aloud to an object, e.g., a duck).
  • Helps reveal gaps and logical mistakes.

• Isolation / divide-and-conquer

  • For large projects (hundreds of lines), split into halves.
  • Comment out sections to narrow down where the bug is.
  • Continue isolating until the cause is found.

---

Clean code principles (how to write understandable, maintainable code)

Core goals

• Clean code should be understandable to humans, not just machines.

Principles mentioned

• Use clear, descriptive names

  • Don’t use meaningless identifiers (e.g., XYZNTOW).
  • Prefer meaningful names like UserEdge.

• Functions should do one task

  • Single-responsibility idea.
  • Avoid “mega-functions” that do multiple unrelated jobs (calculate price + print invoice + email + store in DB, etc.).

• Follow DRY

  • Put repeated logic into functions.

• Keep the solution simple (KES)

  • Avoid unnecessary complexity or “showing off.”

Book recommendation

• “Clean Code” by Robert C. Martin (“Uncle Bob”) is recommended as essential reading.

Comments: what good vs bad comments look like

• Comments are ignored by the compiler/interpreter; they’re for humans.

• Bad comments

  • Restate obvious behavior (e.g., “x = x + 1 means increment x…”).

• Good comments

  • Explain why something was done or warn about important behavior/edge cases
  • Examples:
    • “FixMe crashes if input is …”
    • “Todo add … later”

---

Basic data structures (overview only)

• Data structures are described as the “containers” that hold the program’s data.
• Examples mentioned:
  • Lists / Arrays
  • Linked lists
  • Stack
  • Queue
  • Trees
  • Graphs
• Emphasis: learn that these exist first; details come later.

---

Object-Oriented Programming (OOP) foundations (LAPID pillars)

• OOP is framed as a major approach used for large systems.

• Real-world analogy

  • Real software models objects/entities (cars, humans, accounts, etc.).
  • Each entity has:
    • attributes (data/state)
    • actions (behavior)

Class vs object

• Class: a template/mold that defines structure/blueprint.
• Object: the real instance created from the class.

“Pillars” mentioned (LAPID / four concepts)

1. Encapsulation

   • Gather/enclose/protect internal data.
   • Control access to object data.

2. Abstraction

   • Hide complex internal details.
   • Show only what the user needs.

3. Inheritance

   • Create a new class that reuses/extends a parent class’s characteristics.

4. Polymorphism

   • The same interface/behavior can act differently depending on the object type calling it.

---

Exam & next steps (what to focus on)

• The exam/quiz is described as:

  • surprise
  • covering everything mentioned in lectures and research items
  • not necessarily straightforward questions (more about understanding than memorization)

• Performance guidance

  • Arrive early; ensure internet stability.
  • Confirm the microphone works for typing answers.
  • Focus on conceptual foundation and practice, not memorization.

• Study approach

  • Review recorded lectures and presentation.
  • Use your mind: understand concepts (e.g., flow control) and internalize logic.
  • Re-study progression:
    • imitation → imitation of imitation → invent solutions using logic

---

Speakers / sources featured

Speakers (people mentioned)

• Professor Mohammed Assaf (attendance link sender; referenced multiple times)
• The Engineering lecturer / instructor (main speaker; repeatedly referred to as “engineer”)
• Mohamed (student participant)
• Amr (student participant)
• Ibrahim (student participant)
• Omar (student participant; asked a question)
• Nourhan (student participant; involved in attendance/communication)
• Ahmed (student participant; involved in attendance and questions)
• Louay (used as an analogy name for scope illustration)
• Zak (referenced regarding taking a screenshot)

Sources

• “Clean Code” by Robert C. Martin (Uncle Bob)
• IDE/tools mentioned: Visual Studio Code, PyCharm (for debugging tools)