Scribbles for my bad memory

If you've ever had a code review rejected because of "whitespace-only changes," you're not alone. Nothing frustrates developers more than seeing a perfectly good pull request cluttered with meaningless line ending modifications that make the actual code changes harder to review.

The Problem

Large development teams often work across different operating systems - some on Windows, others on macOS or Linux. Each system has different default line endings (CRLF vs LF), and when developers use different editors with different configurations, innocent file saves can accidentally convert line endings throughout entire files.

The result? Pull requests that show hundreds of "changed" lines when only a few lines actually contain meaningful code changes. GitHub's "Hide whitespace changes" button helps reviewers, but it doesn't solve the root problem.

The Solution: Preserve What Exists

Instead of trying to enforce one line ending standard across a diverse team (which often fails), the better approach is to configure all tools to preserve whatever line endings already exist in each file.

Git Configuration

First, tell Git to stop converting line endings:

git config core.autocrlf false

This tells Git: "Don't touch line endings - leave them exactly as they are."

JetBrains Rider/IntelliJ Configuration

In your IDE settings:

1. Go to File → Settings → Editor → Code Style → General
2. Set "Line separator" to "System-dependent" or "Use existing"
3. Disable Editor → General → On Save → "Ensure every saved file ends with a line break"

This makes Rider detect and preserve the existing line ending style in each file.

VS Code Configuration

Add to your settings.json:

{
  "files.eol": "auto",
  "files.insertFinalNewline": false,
  "files.trimTrailingWhitespace": false
}

The "files.eol": "auto" setting preserves existing line endings per file and only uses system defaults for completely new files.

Team-wide .editorconfig

Create an .editorconfig file in your repository root:

root = true

[*]
# Omit end_of_line to preserve existing line endings
insert_final_newline = false
trim_trailing_whitespace = false

By not specifying end_of_line, most editors will preserve whatever line endings already exist in each file.

Why This Works

This approach acknowledges the reality of mixed development environments while preventing the chaos of constant line ending changes. Files keep their original line endings, new files use sensible defaults, and most importantly - your pull requests only show actual code changes.

The Result

After implementing these settings across your team:

• No more whitespace-only changes cluttering your diffs
• Faster, cleaner code reviews
• Happier team leads and reviewers
• More focus on actual code quality instead of formatting battles

Your future self (and your code reviewers) will thank you for taking the time to set this up properly.

Have you dealt with similar whitespace issues in your team? What solutions worked for you? Share your experiences in the comments below.

1. Prepare Your Icon Image

• Create a square PNG image (preferably 1024x1024 pixels) for best quality

2. Use the flutter_launcher_icons Package

Add the package to your pubspec.yaml:

flutter pub add flutter_launcher_icons

3. Configure the Icons

Add this configuration to your pubspec.yaml file:

flutter_launcher_icons:
  android: true
  ios: true
  remove_alpha_ios: true
  image_path: "assets/icon/app_icon.png"  # Path to your icon image
  adaptive_icon_background: "#FFFFFF"  # For Android adaptive icons (optional)

4. Run the Package

Run this command in your terminal:

flutter pub get
dart run flutter_launcher_icons

done!

在使用 jq 处理 JSON 数据时，我们常常需要从命令行传递变量。jq 提供了两个选项：--arg 和 --argjson，它们用于不同类型的数据。本文介绍这两个选项的区别以及如何正确使用它们。

--arg 与 --argjson

1. 使用 --arg

• 用途：传递字符串值。

• 行为：传递的值被视为字符串，并在 jq 输出的结果中加上引号。

• 示例：

  jq -n --arg name "张三" '{ "name": $name }'
  

  输出结果为：

  {
    "name": "张三"
  }
  

2. 使用 --argjson

• 用途：传递数字、数组或对象等 JSON 值。

• 行为：传递的值被视为原始 JSON，不会加上引号。

• 示例：

  jq -n --argjson age 30 '{ "age": $age }'
  

  输出结果为：

  {
    "age": 30
  }
  

如何选择

• 如果值是字符串，使用 --arg。
• 如果值是数字或其他 JSON 类型，使用 --argjson。

再来个复杂点的例子

jq -n --arg a "Hello" --argjson b 42 '($a + ($b | tostring))'

在这个例子中，字符串 "Hello" 和数字 42 被拼接成 "Hello42"（带引号的字符串），因为我们将数字转换为字符串后再进行连接。

When using sed on Windows, you might run into unexpected behavior, especially with line endings. If you're editing files with Windows-style line endings (\r\n), sed can unintentionally modify them, causing issues with tools like git diff. Here’s how you can use sed effectively on Windows without breaking your line endings.

The Problem: Unexpected \r\n to \n Conversion

On Windows, text files usually use \r\n (carriage return + line feed) as line endings. However, sed, depending on its mode, may treat these as Unix-style \n line endings, removing the \r and leading to issues like:

• Files appearing changed when they shouldn’t.
• Tools like git diff showing extra changes due to the altered line endings.

Solution: Use sed -b to Prevent Line Ending Conversion

To avoid this, you need to force sed to operate in binary mode, which prevents automatic conversion of line endings.

Example:

sed -b 's/old_text/new_text/' filename.txt

In this example:

• The -b flag ensures sed works in binary mode, preserving the \r\n line endings.
• The s/old_text/new_text/ part performs the actual substitution.

set -x && if cd flutter; then git pull && cd .. ; else git clone https://github.com/flutter/flutter.git; (cd flutter && git fetch --tags && git checkout 3.22.3); fi && ls && flutter/bin/flutter doctor && flutter/bin/flutter clean && flutter/bin/flutter config --enable-web && cp .env.production .env && sed -i "s/VERSION_PLACEHOLDER/`git rev-parse --short HEAD`/" .env && flutter/bin/flutter build web --web-renderer html --base-href="/" --release