Free AI Code Reviewer & Refactoring Tool (No Signup Needed)

function getData(u){
  let a = fetch(u).then(r=>r.json()).then(d=>{
    let x = []
    for(let i=0;i<d.length;i++){
      if(d[i].type=="user"){
        x.push(d[i])
      }
    }
    return x
  })
  return a
}

Summary:
The code lacks error handling, uses nested promises instead of async/await for clarity, and has a verbose loop for filtering. Quick wins include converting to async/await, adding try/catch for errors, and using array filter for readability.

Issues:
1. [High] No error handling — fetch or JSON parsing errors will be unhandled — add try/catch.
2. [Medium] Uses nested .then() instead of async/await — reduces readability and maintainability — refactor to async/await.
3. [Low] Manual loop for filtering — verbose and less readable — use Array.prototype.filter.

Quick Fixes:
- Convert function to async and use await for fetch and json parsing.
- Wrap await calls in try/catch to handle errors gracefully.
- Replace for loop with filter to select items with type "user".

async function getData(u) {
  try {
    const response = await fetch(u);
    if (!response.ok) throw new Error('Network response was not ok');
    const data = await response.json();
    return data.filter(item => item.type === "user");
  } catch (error) {
    console.error('Fetch error:', error);
    return [];
  }
}

def find_names(records):
    result = []
    for r in records:
        if r.get("name"):
            result.append(r["name"].strip().lower())
    return list(set(result))

Summary:
The function is readable but can be improved for performance and maintainability by using a set comprehension directly and avoiding multiple lookups. Variable naming can be clearer. The quick win is to replace the loop with a set comprehension and simplify the return.

Issues:
1. [Medium] Inefficient use of list then set conversion — extra memory and processing — use a set comprehension directly.
2. [Low] Variable name 'r' is not descriptive — reduces readability — rename to 'record'.
3. [Low] Multiple dictionary lookups for the same key — minor inefficiency — store the value in a variable.
4. [Low] No input validation or type hints — affects maintainability — add type hints and consider input checks.

Quick Fixes:
- Replace the for-loop and list with a set comprehension that strips and lowers names.
- Rename loop variable to 'record' for clarity.
- Use a single dictionary get call per record.
- Add type hints to the function signature.

Updated Code:
def find_names(records: list[dict]) -> list[str]:
    return list({record["name"].strip().lower() for record in records if record.get("name")})

int total = 0;
for(Order o : orders){
  if(o.status.equals("PAID") || o.status.equals("CAPTURED") || o.status.equals("SETTLED")){
    total += o.amount;
  }
}

Summary:
The code is readable but can be improved for maintainability and slight performance by avoiding repeated string comparisons and using a set for status checks. Using streams can improve readability and conciseness. The quick win is to replace multiple equals checks with a set lookup.

Issues:
1. [Medium] Multiple string comparisons in loop — inefficient and error-prone if statuses change — use a Set for status checks.
2. [Low] Manual accumulation with for-loop — more verbose than necessary — consider using Java streams for clarity.
3. [Low] No null check on order status — potential NullPointerException — add null-safe checks.

Quick Fixes:
- Create a Set of valid statuses and check membership instead of multiple equals.
- Use Java streams with filter and mapToInt for concise summation.
- Add null check for order status before comparison.

Updated Code:
int total = orders.stream()
  .filter(o -> o.status != null && (o.status.equals("PAID") || o.status.equals("CAPTURED") || o.status.equals("SETTLED")))
  .mapToInt(o -> o.amount)
  .sum();

SELECT * FROM orders WHERE status = 'paid' OR status = 'captured' OR status = 'settled';

Summary:
The query uses repetitive OR conditions that reduce readability and may impact performance. Using IN improves clarity and can leverage indexing better. Formatting the query with uppercase keywords and line breaks enhances maintainability.

Issues:
1. [Medium] Repetitive OR conditions — harder to read and less efficient — replace with IN clause.
2. [Low] Lack of formatting — reduces readability and maintainability — format keywords uppercase and clauses on separate lines.
3. [Low] SELECT * usage — may fetch unnecessary columns impacting performance — specify needed columns explicitly.

Quick Fixes:
- Replace OR conditions with IN (status IN ('paid', 'captured', 'settled')).
- Format SQL keywords in uppercase and place each clause on its own line.
- Replace SELECT * with explicit column names if known.

Updated Code:
SELECT *
FROM orders
WHERE status IN ('paid', 'captured', 'settled');

fn run(v: Vec<i32>) -> i32 {
    let mut r = 0;
    for i in v {
        if i > 10 { r += i }
    }
    r
}

Summary:
The main issues are suboptimal readability and missed performance improvements by not using iterator methods. The quick win is to replace the explicit for-loop with iterator combinators like filter and sum for clearer, more idiomatic, and potentially more efficient code.

Issues:
1. [Medium] Uses explicit for-loop with mutation — less idiomatic and harder to read — use iterator methods like filter and sum.
2. [Low] Consumes vector by value — may be unintended if vector is needed later — consider iterating by reference if ownership is not required.
3. [Low] Variable naming is non-descriptive (`r`) — reduces maintainability — use descriptive names like `sum`.

Quick Fixes:
- Replace the for-loop with `v.iter().filter(|&&i| i > 10).sum()`.
- Iterate over references if the vector should not be consumed.
- Rename `r` to `sum` for clarity.

Updated Code:
fn run(v: Vec<i32>) -> i32 {
    v.iter().filter(|&&i| i > 10).sum()
}