我今天在 ADT 里打开一个历史很久的 ABAP CDS Data Definition，第一眼看到的不是业务逻辑，而是一整片挤在一起的字段列表、association、JOIN 条件和 where 条件。字段之间有的换行，有的不换行，关键字大小写也不统一。代码当然可以激活，SQL Preview 也能跑出结果，可一旦要改一个 association 的 on 条件，或者在 element list 里插入一个计算字段，维护体验就会直线下降。CDS 这类对象和传统 ABAP report 不太一样。传统 ABAP 代码里，过程逻辑占据主导，格式不好时还可以靠断点和 call stack 慢慢追。CDS Data Definition 更偏声明式建模，读代码时关注的是实体之间的关系、字段语义、过滤条件、授权相关注解、投影层和接口层的边界。如果格式乱掉，很多设计意图会被淹没在一堆符号里。Formatting Data Definitions 解决的正是这个问题，它把 DDL source code 按统一规则重新排版，让 CDS statement、element list、Boolean expression、JOIN、association definition 等结构变得更清楚。从一个常见的 CDS 维护场景切入在 S/4HANA 项目里，一个销售订单相关的 CDS View Entity 很容易从最初的十几个字段长到几十个字段。项目早期可能只是给 Fiori Elements 列表页提供表头信息，后来又加入客户名称、销售组织、付款条件、交货状态、净额、币种，再往后又被另一个复用视图消费。几轮需求下来，Data Definition 里字段越来越多，associatio
ABAP CDS Data Definition 格式化实践，别让 DDL 代码输在可读性上
我今天在 ADT 里打开一个历史很久的 ABAP CDS Data Definition，第一眼看到的不是业务逻辑，而是一整片挤在一起的字段列表、association、JOIN 条件和 where 条件。字段之间有的换行，有的不换行，关键字大小写也不统一。代码当然可以激活，SQL Preview 也能跑出结果，可一旦要改一个 association 的 on 条件，或者在 element list 里插入一个计算字段，维护体验就会直线下降。CDS 这类对象和传统 ABAP report 不太一样。传统 ABAP 代码里，过程逻辑占据主导，格式不好时还可以靠断点和 call stack 慢慢追。CDS Data Definition 更偏声明式建模，读代码时关注的是实体之间的关系、字段语义、过滤条件、授权相关注解、投影层和接口层的边界。如果格式乱掉，很多设计意图会被淹没在一堆符号里。Formatting Data Definitions 解决的正是这个问题，它把 DDL source code 按统一规则重新排版，让 CDS statement、element list、Boolean expression、JOIN、association definition 等结构变得更清楚。从一个常见的 CDS 维护场景切入在 S/4HANA 项目里，一个销售订单相关的 CDS View Entity 很容易从最初的十几个字段长到几十个字段。项目早期可能只是给 Fiori Elements 列表页提供表头信息，后来又加入客户名称、销售组织、付款条件、交货状态、净额、币种，再往后又被另一个复用视图消费。几轮需求下来，Data Definition 里字段越来越多，associatio
